COMPUTER IMPLEMENTED METHODS, NON-TRANSITIONAL STORAGE MEDIA AND SYSTEMS

专利摘要:
method for making a change to a primary node in a trust network includes a backup node of the trust network determining that an epoch change needs to be made, determining a respective weight of the associated backup node with each of the three phases of a consensus process at a current time, determine a weight sum for the backup node based on the respective weights, sending an epoch_change message to the other network nodes to request a new primary node at a new time, receive new_epoch messages from other network nodes, determine whether a number of valid new_epoch messages exceed a predetermined second threshold, and determine the backup node as the new primary node at the new time in response to the determination of that the number of valid new_epoch messages exceeds the second predetermined threshold.
公开号:BR112019016598A2
申请号:R112019016598-3
申请日:2018-12-13
公开日:2020-03-31
发明作者:Lin Peng
申请人:Alibaba Group Holding Limited；
IPC主号:

专利说明:

"METHODS IMPLEMENTED BY COMPUTER, STORAGE MEDIA NOT TRANSITIONAL AND SYSTEMS" Cross Reference to Related Deposits [001] This application is a continuation of PCT Application ^Nos PCT / CN2018 / 120873, filed on December 13, 2018, which is incorporated by reference in its entirety.
Background of the Invention [002] Distributed accounting systems (DLSs), which can also be called consensus networks and / or trust protocol networks (blockchain), allow participating entities to store data in a secure and immutable way. DLSs are commonly called trust protocol networks without referring to any specific user case. Examples of trust networks can include: public trust networks, private trust networks and consortium trust networks. A public trust protocol network is open for all entities to use DLS and participate in the consensus process. A private trusted protocol network is provided for a specific entity, which centrally controls read and write permissions. A consortium trust protocol network is provided for a select group of entities, which control the consensus process and include an access control layer.
[003] Consensus mechanisms are a primary component of distributed trust protocol systems. A consensus mechanism is a process in computer science that is used to reach agreement on a single data value between distributed processes or systems. Consensus mechanisms are designed to achieve reliability in a network involving several untrusted nodes. Solve this problem Petition 870190097362, of 9/30/2019, p. 9/134
2/91 known as a consensus problem - it is important in distributed and multi-agent computing systems.
[004] The trust protocol depends on consensus mechanisms to reach agreement between us. A trusted protocol is a decentralized database managed by computers distributed over a peer-to-peer (P2P) network. Each part (peer) maintains a copy of the record (ledger) to avoid a single point of failure (SPOF). Updates and validations are reflected in all copies simultaneously.
[005] Although several existing techniques can be used to achieve consensus among network nodes of a reliable protocol system, a more efficient solution for achieving consensus would be advantageous.
Brief Description of the Invention [006] The implementations of this specification include methods implemented by computer to solve consensus problems in a distributed system (for example, a trusted protocol network). More particularly, the implementations of the present invention are intended to effect a change of the primary node in a distributed system.
[007] In some implementations, actions include: determining by a backup node of a trust protocol network that an epoch change needs to be performed, in which the epoch change causes a change of a current epoch with a current primary node for a new era with a new primary node, where the current era includes a consensus process to reach consensus between a number of network nodes using the primary node and where the consensus process includes three phases; determine, by the backup node, a respective weight of the backup node associated with each of the three phases of the consensus process at the current time; determine a sum of weight
Petition 870190097362, of 09/30/2019, p. 10/134
3/91 for the backup node by the backup node based on the respective weight of the backup node associated with each of the three phases at the current time; send an EPOCH_CHANGE message through the backup node to the number of network nodes other than the network node in response to the determination that the weight sum reaches a predetermined first threshold, where the EPOCH_CHANGE message indicates a request for a change of the current epoch with the current primary node for the new epoch, with the backup node being the new primary node, and EPOCH-CHANGE includes the weight sum of the backup node; receive at least one NEW_EPOCH message by the backup node from at least a number of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation that the backup node is the new primary node ; check by the backup node if at least one NEW_EPOCH message is valid; determine by the backup node if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and determining that the backup node is the new primary node in the new epoch by the backup node in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold.
[008] Other implementations include systems, devices and corresponding computer programs, configured to perform the actions of the methods, encoded in computer storage devices.
[009] These and other implementations may optionally include one or more of the following characteristics:
A first feature, combinable with any of the following features, where the backup node determines a weight of the backup node for a
Petition 870190097362, of 09/30/2019, p. 11/134
4/91 first phase of the consensus process as a first value.
[0010] A second characteristic, combinable with any of the following characteristics, in which the backup node determines a weight of the backup node for the second phase of the consensus process as being a first value in response to the determination of a failure to verify the quorum in a second phase of the consensus process at the current time and the backup node determines that the weight of the backup node for the second phase of the consensus process is a second value greater than the first value in response to determining the success of a quorum check in the second phase of the consensus process today.
[0011] A third characteristic, which can be combined with any of the following characteristics, in which the verification of the quorum in the second phase of the network node includes receiving a predetermined number of ECHO messages from other network nodes.
[0012] A fourth characteristic, combinable with any of the following characteristics, in which the backup nodes determine a weight of the backup node for the third stage of the consensus process as being a third value in response to the determination of a failure of a quorum check in a third phase of the consensus process at the present time, and the backup node determines that the weight of the backup node for the third phase of the consensus process is a fourth value greater than the third value in response to determining the success of a quorum check in the third phase of the consensus process at the present time.
[0013] A fifth characteristic, combinable with any of the following characteristics, in which the quorum verification in the third phase
Petition 870190097362, of 09/30/2019, p. 12/134
5/91 for the network node comprises receiving a predetermined number of acceptance messages from other network nodes, wherein each of the acceptance messages from other network nodes indicates that each of the other network nodes has accepted a predetermined number of ECHO messages.
[0014] A sixth characteristic, combinable with any of the following characteristics, in which the EPOCH_CHANGE message also includes a set of signatures associated with a set of network nodes of the number of network nodes and in which the NEW_EPOCH message includes a summary of the EPOCH_ CHANGE message.
[0015] A seventh characteristic, combinable with any of the following characteristics, in which to verify that at least one valid NEW_EPOCH message is valid, includes checking that the summary of the EPOCH_CHANGE message in at least one NEW_EPOCH message is valid.
[0016] An eighth characteristic, combinable with any of the following characteristics, in which to verify that the summary of the EPOCH_CHANGE message in at least one NEW_EPOCH message is valid, includes verifying that the signature set in the EPOCH_CHANGE message is valid.
[0017] A ninth characteristic, combinable with any of the following characteristics, in which the backup nodes determine that an epoch change needs to be performed in response to the determination that consensus was not reached in the ancient epoch within a period predetermined time.
[0018] A tenth characteristic, combinable with any of the following characteristics, in which the new era includes a consensus process to obtain consensus among the number of network nodes using the new primary node.
Petition 870190097362, of 09/30/2019, p. 13/134
6/91 [0019] In some implementations, the actions include: receiving, through a network node of several network nodes, an EPOCH_CHANGE message from a backup node other than the network node, where the message EPOCH_CHANGE includes a indication that a time change needs to be performed, where the time change causes a change from a current time with a current primary node to a new time with a new primary node; check, by the network node, if the EPOCH_CHANGE message is valid; in response to verifying that the EPOCH_CHANGE message is valid, send, via the network node, a NEW_EPOCH message to the other network nodes, where the NEW_EPOCH message includes a summary of the EPOCH_CHANGE message; receiving at least one NEW_EPOCH message from at least one of the number of network nodes other than the network node by the network node; check, by the network node, if at least one NEW_EPOCH message is valid; determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold, determine, by the network node, the backup node to be the new primary node in the new era.
[0020] Other implementations include systems, devices and corresponding computer programs, configured to perform the actions of the methods, encoded in computer storage devices.
[0021] These and other implementations may optionally include one or more of the following characteristics:
A first feature, which can be combined with any of the following features, where the EPOCH_CHANGE message includes a sum of weight associated with the backup node and a set of
Petition 870190097362, of 09/30/2019, p. 14/134
7/91 subscriptions associated with a set of network nodes out of the number of network nodes.
[0022] A second characteristic, which can be combined with any of the following characteristics, in which checking whether the EPOCH_CHANGE message is valid includes checking whether the weight sum in the EPOCH_CHANGE message is valid, in which checking whether the weight sum in the EPOCH_CHANGE message is valid includes verifying that set of signatures are valid.
[0023] A third characteristic, which can be combined with any of the following characteristics, in which to verify that at least one NEW_EPOCH message is valid, includes checking whether the summary of the EPOCH_CHANGE message in at least one NEW_EPOCH message is valid and in which checking whether the summary of the EPOCH_CHANGE message in at least one NEW_EPOCH message is valid includes verifying that the signature set in the EPOCH_CHANGE message is valid.
[0024] The present invention also provides one or more non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored on it that, when executed by one or more processors, cause one or more processors to execute operations in accordance with implementations of the methods provided here.
[0025] The present invention further provides a system for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to one or more processors having instructions stored in it that, when executed by one or more processors, cause one or more processors to perform operations according to implementations of the methods provided here.
Petition 870190097362, of 09/30/2019, p. 15/134
8/91 [0026] The present invention discloses better consensus mechanisms, including techniques for reaching consensus between network nodes in a distributed system, performing a primary node change in a distributed system and performing a recovery process for a node network in a distributed system. The consensus mechanisms described can achieve several advantages in different applications.
[0027] For example, the consensus process, as discussed below, includes many features that improve the operations of the trust protocol system and help alleviate the bottleneck in the network. For example, the consensus process described includes converting a transaction request into a number of elimination code (EC) blocks according to an EC code and sending one of the EC blocks to each of the network nodes. The EC block is smaller in size than the original transaction request. Thus, sending the EC block instead of the complete transaction request to the network nodes reduces the size of the data blocks that are transmitted between the network nodes of the trust protocol network, thereby conserving the network bandwidth and reducing the network load. This further reduces the size of the data that is written to and read from the memory space of the network nodes, thereby reducing the load on the memory space of the network nodes and improving the efficiency of the generally trusted protocol system.
[0028] In addition, this specification describes a time change process that includes assigning respective weights to multiple phases of the consensus process, determining a sum of weight based on the respective weights of the multiple phases and determining a new primary node with based on the sum of weight. The epoch change process based on the sum of weight instead of a round robin method can facilitate the choice of a new primary node that is not defective in a timely manner. Unlike the round robin method, the time change process in the
Petition 870190097362, of 09/30/2019, p. 16/134
9/91 this specification relies on the weight sum to select the new primary node, which can reduce latency or delay in locating the new primary node that is not defective. This can further improve the efficiency of the general trust protocol system in providing trust protocol services.
[0029] In addition, this specification discusses a recovery process that includes operations such as sending a status request message through a network node that applies to be a new primary node and receiving status response messages from other network nodes. These operations are performed in such a way that the failed network node recovery process does not interfere with the normal operation of the consensus process among the other non-defective network nodes. This makes it easier to conserve computing and network resources to recover the failed network node, reducing the complexity of the recovery process.
[0030] It is known that the methods according to the present invention can include any combination of the aspects and characteristics described herein. That is, the methods according to the present invention are not limited to the combinations of aspects and characteristics specifically described herein, but also include any combination of the aspects and characteristics provided.
[0031] Details of one or more implementations of the present invention are presented in the attached drawings and in the description below. Other features and advantages of the present invention will be apparent from the description and drawings, and from the claims.
Description of the Drawings [0032] Figure 1 represents an example of an environment that can be used to perform implementations of the present invention.
[0033] Figure 2 represents an example of an architecture
Petition 870190097362, of 09/30/2019, p. 17/134
10/91 conceptual according to implementations of the present invention.
[0034] Figure 3 represents an example of a consensus process that can be performed according to implementations of the present invention.
[0035] Figure 4 represents an example of a consensus process that can be performed according to implementations of the present invention.
[0036] Figure 5 represents an example of a hash tree according to implementations of the present invention.
[0037] Figure 6 represents an example of messages that are communicated between network nodes of a distributed system according to implementations of the present invention.
[0038] Figure 7 represents an example of a process of making a change to a primary node in a distributed system according to implementations of the present invention.
[0039] Figure 8 represents an example of a process of making a change to a primary node in a distributed system according to implementations of the present invention.
[0040] Figure 9 represents an example of messages that are communicated between network nodes of a distributed system according to implementations of the present invention.
[0041] Figure 10 represents an example of a process for carrying out a recovery process for a network node in a distributed system according to the implementations of the present invention.
[0042] Figure 11 represents an example of a process for carrying out a recovery process for a network node in a distributed system according to implementations of the present invention.
[0043] Figure 12 represents an example of messages that
Petition 870190097362, of 09/30/2019, p. 18/134
11/91 are communicated between network nodes of a distributed system according to implementations of the present invention.
[0044] Figure 13 represents an example of a diagram representing modules of a consensus apparatus, according to an implementation of the present invention.
[0045] Figure 14 represents an example of a diagram representing modules of a consensus apparatus, according to an implementation of the present invention.
[0046] Figure 15 represents an example of a diagram representing modules of a primary node alteration apparatus, according to an implementation of the present invention.
[0047] Figure 16 represents an example of a diagram illustrating modules of a primary node change apparatus, according to an implementation of the present invention.
[0048] Figure 17 represents an example of a diagram representing modules of a recovery device, according to an implementation of the present invention.
[0049] Similar reference symbols in the various drawings indicate similar elements.
Detailed Description of the Invention [0050] The implementations of the present description include methods implemented by computer to resolve consensus issues in a distributed system (for example, a trusted protocol network). More particularly, the implementations of the present invention are intended to effect a change of the primary node in a distributed system.
[0051] In some implementations, the actions include: determining by a backup node of a trust protocol network that an epoch change needs to be performed, in which the
Petition 870190097362, of 09/30/2019, p. 19/134
12/91 epoch change causes a change from a current epoch with a current primary node to a new epoch with a new primary node, where the current epoch includes a consensus process to achieve consensus between a number of network nodes using the primary node and where the consensus process includes three phases; determine, by the backup node, a respective weight of the backup node associated with each of the three phases of the consensus process at the current time; determine a sum of weight for the backup node by the backup node based on the respective weight of the backup node associated with each of the three phases at the current time; send an EPOCH_CHANGE message through the backup node to the number of network nodes other than the network node in response to the determination that the weight sum reaches a predetermined first threshold, where the EPOCH_CHANGE message indicates a request for a change of current epoch with the current primary node for the new epoch, with the backup node being the new primary node, and EPOCH-CHANGE includes the weight sum of the backup node; receive at least one NEW_EPOCH message by the backup node from at least a number of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation that the backup node is the new primary node ; check by the backup node if at least one NEW_EPOCH message is valid; determine by the backup node if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and determining that the backup node is the new primary node in the new epoch by the backup node in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold.
[0052] In some implementations, actions include: receiving,
Petition 870190097362, of 09/30/2019, p. 20/134
13/91 by a network node of several network nodes, an EPCOH_CHANGE message from a backup node other than the network node, where the EPOCH_CHANGE message includes an indication that a time change needs to be performed, where the epoch change causes a change from a current epoch with a current primary node to a new epoch with a new primary node; check, by the network node, if the EPOCH_CHANGE message is valid; in response to verifying that the EPOCH_CHANGE message is valid, send a NEW_EPOCH message to the other network nodes through the network node, where the NEW_EPOCH message includes a summary of the EPOCH_CHANGE message; receive at least one NEW_EPOCH message from at least one of several network nodes other than the network node by the network node; check, by the network node, if at least one NEW_EPOCH message is valid; determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold, determine, by the network node, the backup node to be the new primary node in the new era.
[0053] To provide an additional context for implementations of the present invention, and as was introduced above, distributed accounting systems (DLSs), which can also be referred to as consensus networks (for example, made up of peer-to-peer nodes ) or trusted protocol networks, allow participating entities to carry out transactions in a secure and immutable way and to store data. The term trust protocol is used here to refer generally to a DLS without reference to any particular use case. As introduced above, a trust protocol network can be provided as a public trust protocol network, a private trust protocol network, or a network
Petition 870190097362, of 09/30/2019, p. 21/134
14/91 of consortium trust protocol.
[0054] A trust protocol is a data structure that stores transactions in order to allow future transactions to be checked for consistency with all previous transactions stored in the chain. A trust protocol includes one or more blocks. Each block in the chain is linked to a previous block immediately before it in the chain, including a cryptographic hash of the previous block. Each block also includes a timestamp, its own cryptographic hash and one or more transactions. The transactions, which have already been verified by the trust protocol network nodes, are hashed (obscured so that they cannot be read) and encoded in a Merkle tree. A Merkle tree is a data structure in which the data in the leaf nodes of the tree is obscured and all obscured in each branch of the tree are concatenated at the root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all the data in the tree. A hash of a transaction supposedly stored in the tree can be checked quickly by determining whether it is consistent with the structure of the tree.
[0055] While a trust protocol is a data structure for storing transactions, a trust protocol network is a network of computing nodes that manages, updates and maintains one or more trust protocol structures. As shown above, a trust protocol network can be provided as a public trust protocol network, a private trust protocol network, or a consortium trust network.
[0056] In a public trust protocol network, the consensus process is controlled by consensus network nodes. For example, hundreds, thousands and even millions of entities can cooperate in
Petition 870190097362, of 09/30/2019, p. 22/134
15/91 a public trust protocol network, each operating at least one node in the public trust protocol network. Thus, the public trust protocol network can be considered a public network in relation to the participating entities. In some examples, most entities (nodes) must sign each block for the block to be valid and added to the trust protocol (distributed record) of the trust protocol network. Examples of public trust protocol networks include private peerto-peer payment networks that use a distributed registry, referred to as a trust protocol. As noted above, the term trust protocol, however, is used to generally refer to records distributed without particular reference to any particular trust protocol network.
[0057] In general, a public trust protocol network supports public transactions. A public transaction is shared with all nodes within the public trust protocol network and is stored in a global trust protocol. A global trust protocol is a trust protocol that is replicated across all nodes. That is, all nodes are in a perfect state of consensus regarding the global trust protocol. To reach consensus (for example, agreeing to add a block to a trust protocol), a consensus protocol is implemented in the public trust protocol network. Examples of consensus protocols include, without limitation, proof of work (POW), proof of participation (POS) and proof of authority (POA). POW is referred to here as a non-limiting example.
[0058] In general, a private trust protocol network is provided for a specific entity, which centrally controls read and write permissions. The entity controls which nodes are able to participate in the trust protocol network, therefore, the protocol networks
Petition 870190097362, of 09/30/2019, p. 23/134
16/91 private trusts are often called permission networks that place restrictions on who can participate in the network and their level of participation (for example, only in certain transactions). Various types of access control mechanisms can be used (for example, existing participants vote to add new entities, a regulatory authority can control admission).
[0059] In general, a consortium trust protocol network is private between participating entities. In a consortium trust protocol network, the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (for example, a financial institution, insurance company). For example, a consortium of ten (10) entities (for example, financial institutions, insurance companies) may operate a consortium trust protocol network, each operating at least one node in the consortium trust protocol network. In this sense, the consortium trust protocol network can be considered a private network in relation to the participating entities. In some examples, each entity (node) must sign all blocks for the block to be valid and added to the trust protocol. In some examples, at least a subset of entities (nodes) (for example, at least 7 entities) must sign all blocks for the block to be valid and added to the trust protocol.
[0060] The implementations of the present description are described in more detail here with reference to a consortium trust protocol network. It is contemplated, however, that the implementations of the present invention can be performed on any appropriate type of trusted protocol network.
[0061] The implementations of the present description are described in more detail here in view of the above context. More particularly, and
Petition 870190097362, of 09/30/2019, p. 24/134
17/91 as presented above, the implementations of the present invention are intended to perform a recovery process for a network node in a distributed system.
[0062] A trust protocol is a tamper-proof shared digital record that records transactions on a public or private peer-to-peer network. The record is distributed to all network member nodes and the history of asset transactions occurring on the network is permanently recorded in the block.
[0063] Consensus mechanisms ensure that all network nodes in a distributed trust protocol network execute transactions in the same order and then write to the same records. One issue that consensus models are intended to address is to overcome Byzantine flaws. In a Byzantine failure, a component such as a server or a network node in a distributed trust protocol network can appear inconsistently with both failure and functioning with fault detection systems, presenting different symptoms to different observers. It is difficult for other network nodes to declare that it failed and disconnect it from the network, because they must first reach a consensus on which network node failed in the first place.
[0064] In the context of distributed systems, Byzantine fault tolerance (BFT) is the ability of a distributed computer network to function as desired and correctly reach a sufficient consensus despite malicious components (ie network nodes of a network of trust protocol) of the system fail or propagate incorrect information to other peers. The objective is to defend against catastrophic system failures, mitigating the influence that these malicious nodes have on the correct functioning of the network and the correct consensus reached by honest nodes in the system.
Petition 870190097362, of 09/30/2019, p. 25/134
18/91 [0065] However, the existing BFT mechanisms have proven to be inefficient in many ways. For example, existing BFT mechanisms have added implementation complexity to the distributed trust protocol network when trying to overcome Byzantine failures, so that latency is increased for communication between network nodes in the distributed trust protocol network. Practical Byzantine Fault Tolerance (PBFT) is one of the optimizations that aims to improve the existing consensus mechanisms in BFT. The PBFT model focuses on providing practical Byzantine state machine replication that tolerates Byzantine failures (malicious nodes) by assuming that there are independent node failures and manipulated messages that are propagated by specific, independent nodes.
[0066] In the PBFT model, all nodes are ordered in a sequence, with one node being the primary node (leader) and the others referred to as backup nodes. All nodes within the system communicate with each other and the goal is for most honest nodes to agree on the state of the system. The nodes communicate with each other and not only need to prove that the messages came from a specific node, but they also need to verify that the message has not been modified during transmission.
[0067] For the PBFT model to work, it is assumed that the number of malicious nodes in the network cannot simultaneously equal or exceed 1/3 of the general nodes in the system in a given vulnerability window. The more nodes in the system, the more mathematically it is unlikely that a number that approaches 1/3 of the general nodes is malicious. The algorithm effectively provides both liveliness and security, provided that at most (n-1) / 3 nodes are malicious or defective at the same time, where n represents the total nodes.
[0068] Each PBFT consensus round (called
Petition 870190097362, of 09/30/2019, p. 26/134
19/91 views) includes 4 phases:
(1) A customer sends a request to the leader node to invoke a service operation;
(2) The leader node multi-transmits the request to the backup nodes;
(3) The nodes execute the request and then send a response to the customer; and (4) The client waits for f + 1 (f represents the maximum number of nodes that may be defective) responses from different nodes with the same result.
[0069] The end result is that all honest nodes reach an agreement on the order of registration and they accept or reject it. The leader node is changed in a round robin scheme during each view and can even be replaced by a protocol called view change if a specific amount of time has passed without the leader node multi-transmitting the request. Most honest nodes can also decide if a leader is defective and remove them with the next leader in line as a replacement.
[0070] However, there are some limitations to the PBFT consensus mechanism. For example, the PBFT model can work well in its classic form, with relatively small consensus group sizes, due to the large amount of communication required between nodes. Bulky block data that is transmitted between network nodes causes a network load problem and leads to a network bottleneck. In addition, the use of method authentication codes (MAC) as the format for authentication messages in the PBFT model can be inefficient with the amount of communication required between nodes in large consensus groups, such as cryptocurrency networks and with MACs. There may be a
Petition 870190097362, of 09/30/2019, p. 27/134
20/91 inherent inability to prove the authenticity of messages to third parties.
[0071] Furthermore, finding consecutive malicious nodes when changing the leader node using a round robin method used by PBFT affects the trust protocol service, introducing latency or delay in locating a leader node that is honest. For example, when selecting a first network node as the new leader node, the first network node can be a malicious node, so it cannot be selected as the new leader node. In a round robin method, a second network node on the line can be selected as the new leader node. However, if the second network node is also a malicious node, another network node on the line will be checked to see if it is suitable to be the leading node. This process continues until a new leader that is honest is identified. This frequent change to the leader node introduces significant latency in trusted protocol services.
[0072] In addition, network nodes in a trusted protocol network can experience Byzantine failures or failures at any time. For example, a network node can be compromised by a malicious cyber attacker and behave incorrectly. If network nodes that are compromised are not recovered immediately, the malicious cyber attacker can compromise the trusted protocol network and services by corrupting more than 1/3 of the network nodes undetected.
[0073] To address the issues and concerns described above associated with the consensus mechanisms existing in the BFT and the consensus mechanism of the PBFT, the present invention reveals improved consensus mechanisms including techniques for achieving consensus between network nodes in a distributed system , performing a primary node change on a distributed system and performing a recovery process for a network node on a distributed system. The consensus mechanisms described can
Petition 870190097362, of 09/30/2019, p. 28/134
21/91 achieve several advantages in different applications.
[0074] For example, the consensus process, as discussed below, includes many features that improve the operations of the trust protocol system and help alleviate the bottleneck in the network. For example, the consensus process described includes converting a transaction request into a number of elimination code (EC) blocks according to an EC code and sending one of the EC blocks to each of the network nodes. The EC block is smaller in size than the original transaction request. Thus, sending the EC block instead of the complete transaction request to the network nodes reduces the size of the data blocks that are transmitted between the network nodes of the trust protocol network, thereby conserving the network bandwidth and reducing the network load. This further reduces the size of the data that is written to and read from the memory space of the network nodes, thereby reducing the load on the memory space of the network nodes and improving the efficiency of the generally trusted protocol system.
[0075] In addition, the present invention describes a time change process that includes assigning respective weights to multiple stages of the consensus process, determining a weight sum based on the respective weights of the multiple stages and determining a new primary node based on in the sum of weight. The epoch change process based on the sum of weight instead of a round robin method can facilitate the choice of a new primary node that is not defective in a timely manner. A primary node can be a leader node that has the authority to initiate a round of consensus process between several network nodes, including the primary node. The other network nodes in the trust protocol network can be referred to as backup nodes. The epoch change process can help to solve the problem of the round robin method that causes a frequent change of the primary node when several network nodes in the line to the new primary node have
Petition 870190097362, of 09/30/2019, p. 29/134
Defect. Unlike the round robin method, the time change process in the current invention depends on the sum of weight to select the new primary node, which can reduce latency or delay in locating the new primary node that is not defective. This can further improve the efficiency of the general trust protocol system in providing trust protocol services.
[0076] In addition, the present invention discusses a recovery process that includes operations such as sending a status request message through a network node that applies to be a new primary node and receiving status response messages from others network nodes. These operations are performed in such a way that the failed network node recovery process does not interfere with the normal operation of the consensus process among the other non-defective network nodes. This makes it easier to conserve computing and network resources to recover the failed network node, reducing the complexity of the recovery process.
[0077] Figure 1 represents an example of an environment (100) that can be used to perform implementations of the present invention. In some examples, the environment (100) allows entities to participate in a consortium trust protocol network (102). The environment (100) includes computing devices or systems (106, 108) and a network (110). In some examples, the network (110) includes a local area network (LAN), wide area network (WAN), the Internet or a combination of them, and connects websites, user devices (for example, computing devices ) and backend systems. In some examples, the network (110) can be accessed via a wired and / or wireless communication link. In some instances, the network (110) allows communication with, and within the consortium trust protocol network (102). In general, the network (110) represents one or more communication networks. In some cases, computing devices (106,
Petition 870190097362, of 09/30/2019, p. 30/134
23/91
108) can be nodes of a cloud computing system (not shown) or each computing device (106, 108) can be a separate cloud computing system including a plurality of computers interconnected by a network and functioning as a system of distributed processing.
[0078] In the example shown, the computing systems (106, 108) can each include any appropriate computing system that allows participation as a node in the consortium trust protocol network (102). Examples of computing devices include, without limitation, a server, a desktop computer, a laptop, a tablet computing device and a smartphone. In some examples, the computing systems (106, 108) host one or more services implemented per computer to interact with the consortium trust protocol network (102). For example, the computing system (106) can host computer-implemented services from a first entity (for example, user A), such as the transaction management system that the first entity uses to manage its transactions with one or more entities ( for example, other users). The computing system (108) can host computer-implemented services from a second entity (for example, user B), such as the transaction management system that the second entity uses to manage its transactions with one or more other entities (for example , other users). In the example in Figure 1, the consortium trust protocol network (102) is represented as a network of peer-to-peer nodes, and the computing systems (106,108) provide nodes of the first entity and second entity, respectively, which participate in the consortium trust protocol network (102).
[0079] Figure 2 represents an example of an architecture
Petition 870190097362, of 09/30/2019, p. 31/134
Conceptual 24/91 (200) according to implementations of the present invention. The example of a conceptual architecture (200) includes the participating systems (202, 204, 206) that correspond to Participant A, Participant B and Participant C, respectively. Each participant (for example, user, company) participates in a trust protocol network (212) provided as a peer-to-peer network including a plurality of nodes (214), at least some of which record immutable information in a protocol of trust (216). Although a single trust protocol (216) is represented schematically within the trust protocol network (212), multiple copies of the trust protocol (216) are provided and maintained through the trust protocol network (212), as here described in more detail.
[0080] In the example shown, each participating system (202, 204, 206) is provided by, or on behalf of Participant A, Participant B and Participant C, respectively, and functions as a respective node (214) within the protocol network reliable. As used here, a node generally refers to an individual system (for example, computer, server) that is connected to the trust protocol network (212), and allows a respective participant to participate in the trust protocol network. In the example in Figure 2, one participant corresponds to each node (214). It is contemplated, however, that a participant can operate multiple nodes (214) within the trust protocol network (212), and / or multiple participants can share a node (214). In some instances, participating systems (202, 204, 206) communicate with, or through, the trust protocol network (212) using a protocol (for example, secure hypertext transfer protocol (HTTPS)) and / or using remote procedure calls (RPCs).
[0081] Nodes (214) can have different degrees of participation
Petition 870190097362, of 09/30/2019, p. 32/134
25/91 within the trust protocol network (212). For example, some nodes (214) may participate in the consensus process (for example, as monitoring nodes that add blocks to the trust protocol (216)), while other nodes (214) do not participate in the consensus process. As another example, some nodes (214) store a complete copy of the trust protocol (216), while other nodes (214) only store copies of parts of the trust protocol (216). For example, data access privileges can limit the trust protocol data that a respective participant stores within its respective system. In the example of Figure 2, the participating systems (202, 204, 206) store their respective complete copies (216 ’, 216”, 216 ”’) of the trust protocol (216).
[0082] A trust protocol (for example, the trust protocol (216) in Figure 2) is made up of a chain of blocks, each block storing data. Examples of data include transaction data representative of a transaction between two or more participants. While transactions are used here by way of non-limiting example, it is envisaged that any appropriate data can be stored in a trusted protocol (for example, documents, images, videos, audio). Examples of transactions may include, without limitation, exchanges of something of value (for example, assets, products, services and currency). The transaction data is immutable stored within the trust protocol. That is, the transaction data cannot be changed.
[0083] Before storing in a block, the transaction data is encrypted. Hashing is a process of transforming the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is not possible to nail the hash value to get the transaction data. Hashing ensures that even a small change to the transaction data results in a
Petition 870190097362, of 09/30/2019, p. 33/134
26/91 completely different hash value. In addition, and as noted above, the hash value is fixed in length. That is, no matter the size of the transaction data, the size of the hash value is fixed. Hashing includes processing the transaction data using a hash function to generate the hash value. An example of a hash function includes, without limitation, the hash secure (SHA) -256 algorithm, which generates 256-bit hash values.
[0084] Transaction data from multiple transactions is encrypted and stored in one block. For example, the hash values for two transactions are provided and are themselves hashed to provide another hash. This process is repeated until, so that all transactions are stored in one block, a single hash value is provided. This hash value is referred to as a Merkle root hash and is stored in a block header. A change in any of the transactions will result in changes in the hash value and, ultimately, a change in the hash of the Merkle root.
[0085] The blocks are added to the trust protocol through a consensus protocol. Multiple nodes within the trust protocol network participate in the consensus protocol and compete to have a block added to the trust protocol. These nodes are referred to as miners (or observer nodes). POW, introduced above, is used as a non-limiting example.
[0086] Mining nodes perform the consensus process to add transactions to the trust protocol. Although multiple mining nodes participate in the consensus process, only one mining node can write the block to the trust protocol. That is, mining nodes compete in the consensus process to have their block added to the trust protocol. In more detail, a mining node periodically collects pending transactions from a transaction pool (e.g.,
Petition 870190097362, of 09/30/2019, p. 34/134
27/91 up to a predefined threshold in the number of transactions that can be included in a block, if any). The transaction pool includes transaction messages from participants in the trust protocol network. The mining node builds a block and includes transactions in the block. Before adding the transactions to the block, the mining node checks whether any of the transactions are already included in a block of the trust protocol. If a transaction is already included in another block, the transaction will be discarded.
[0087] The mining node generates a block header, hashes all transactions in the block and combines the hash value in pairs to generate more hash values until a single hash value is provided for all transactions in the block (the hash of Merkle root). This hash is added to the block header. The miner also determines the hash value of the most recent block in the trust protocol (that is, the last block added to the trust protocol). The mining node also includes a nonce value and a timestamp for the block header. In a mining process, the mining node tries to find a hash value that meets the required parameters. The mining node continues to change the nonce value until it finds a hash value that meets the required parameters.
[0088] Each miner in the trust protocol network tries to find a hash value that meets the necessary parameters and, in this way, compete with each other. Eventually, one of the mining nodes finds a hash value that meets the required parameters and announces this to all other mining nodes in the trust protocol network. The other mining nodes verify the hash value and, if determined to be correct, verify each transaction in the block, accept the block and attach the block to its copy of the trust protocol. In this way, a global state of the trust protocol is consistent across all mining nodes within the trust protocol network. The process described above is the consensus protocol
Petition 870190097362, of 09/30/2019, p. 35/134
28/91 POW.
[0089] A non-limiting example is provided with reference to Figure 2. In this example, Participant A wants to send a fund amount to Participant B. Participant A generates a transaction message (for example, including the From, To fields and Value) and sends the transaction message to the trust protocol network, which adds the transaction message to a transaction pool. Each mining node in the trust protocol network creates a block and takes all transactions from the transaction pool (for example, up to a predefined threshold in the number of transactions that can be added to a block, if any) and adds the transactions to the block . In this way, the transaction published by Participant A is added to the blocks of the mining nodes.
[0090] In some trust protocol networks, encryption is implemented to maintain transaction privacy. For example, if two nodes want to keep a transaction private, so that other nodes in the trust protocol network cannot discern details of the transaction, the nodes can encrypt the transaction data. Examples of cryptographic methods include, without limitation, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key for encryption (generation of cipher text from plain text) and decryption (generation of plain text from cipher text). In symmetric encryption, the same key is available for multiple nodes, so each node can encrypt the transaction data.
[0091] Asymmetric cryptography uses key pairs that include a private key and a public key, the private key being known only to a respective node and the public key being known to any or all of the other nodes in the trust protocol network . A node can
Petition 870190097362, of 09/30/2019, p. 36/134
29/91 use another node's public key to encrypt data and the encrypted data can be decrypted using another node's private key. For example, and referring again to Figure 2, Participant A can use Participant B's public key to encrypt data and send the encrypted data to Participant B. Participant B can use his private key to decrypt the encrypted data ( cipher text) and extract the original data (plain text). Messages encrypted with a node's public key can only be decrypted using the node's private key.
[0092] Asymmetric cryptography is used to provide digital signatures, which allows participants in a transaction to confirm other participants in the transaction, as well as the validity of the transaction. For example, one node can digitally sign a message and another node can confirm that the message was sent by the node based on Participant A.'s digital signature. Digital signatures can also be used to ensure that messages are not tampered with in transit. For example, and again referring to Figure 2, Participant A must send a message to Participant B. Participant A hashes the message and, using his private key, encrypts the hash to provide a digital signature as the encrypted hash. Participant A attaches the digital signature to the message and sends the message with digital signature to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash. Participant B hashes the message and compares the hashes. If the hashes are the same, Participant B can confirm that the message was actually from Participant A and has not been tampered with.
[0093] Figure 3 represents an example of a process (300) to reach a consensus between network nodes (for example, node (214)) of a
Petition 870190097362, of 09/30/2019, p. 37/134
30/91 distributed system (e.g., trust protocol network (102 and 212)) that can be performed according to implementations of the present invention. Specifically, Figure 3 represents a diagram showing an exemplary embodiment of a method (300) of reaching consensus in a normal case, according to the present invention. As illustrated in Figure 3, the consensus process (300) includes three phases or steps (310, 320 and 330) as discussed below.
[0094] In a first phase (310) of the consensus process (300), a primary node (or a leader node) of the trust protocol network sends a first message to the other network nodes (that is, the backup). The first message indicates that the primary node is starting a consensus process. For example, as illustrated in Figure 3, the primary node Ro sends an INITIAL message to the other nodes of networks Ri, R2 and Rana trust protocol network. Note that process (300) is represented as including four network nodes Ro, Ri, R2 and R3 for illustrative purposes only, process (300) can include any suitable number of network nodes. The first phase and format of the INITIAL message will be discussed below in greater detail with reference to Figures 4 to 6.
[0095] In a second phase (320) of the consensus process (300), each of the backup nodes receives the first message that is sent by the primary node, prepares a second message in response to the first message and sends the second message to 0 other network node. The second message indicates that the backup node received the first message from the primary node and is sending a response in response to the first message. For example, as illustrated in Figure 3, the backup node R1 receives the initial message that is sent by the primary node Ro, and responds to the primary node Ro with an ECHO message as an example of the second message. Meanwhile, the backup node R1
Petition 870190097362, of 09/30/2019, p. 38/134
31/91 also multi-transmits the ECHO message to other backup nodes, such as backup nodes R2 and R3. Likewise, the node support of R2 and R3 each multi-transmit an ECHO message to the other network nodes including the primary node Ro.
[0096] When a network node, for example, as a primary node or a backup node, receives ECHO messages from other network nodes, the network node can verify the information in ECHO messages. The second phase and format of the ECHO message will be discussed below in greater detail with reference to Figures 4 to 6.
[0097] In a third phase (330) of the consensus process (300), each of the multi-network nodes transmits a third message to the other network nodes. The third message indicates that a network node has accepted a predetermined number of second messages. In some implementations, the third message may indicate that the network node is ready to perform the transaction. In some implementations, the third message may indicate that the transaction has been successfully rebuilt on the network node. For example, as illustrated in Figure 3, primary node Ro multitransmits an ACCEPT message to backup nodes R1, R2, and R3. Likewise, backup nodes R1, R2, and Rscada multi-transmit an ACCEPT message to other network nodes. In some implementations of the present invention, prior to the multi-transmission of the ACCEPT message, a network node determines whether 0 ACCEPT is sent according to a deletion code (EC) and the information in the ECHO messages is that received in the second phase. The third phase, the EC code, and an ACCEPT message format will be discussed in more detail below with reference to Figures 4 to 6.
[0098] When a network node receives sufficient ACCEPT messages from the other network nodes, the network node determines that a consensus
Petition 870190097362, of 09/30/2019, p. 39/134
32/91 has been achieved. For example, if primary node Ro or backup nodes Ri, R20U R3 receive a quorum number (for example, 2f + 1, where f represents a number of faulty network nodes) for ACCEPT messages, a consensus is reached automatically between network nodes.
[0099] Figure 4 represents an example of a process (400) for obtaining consensus between network nodes (for example, node (214) or Ro, R1, R2 and R3 nodes) of a distributed system (for example, network of trust protocol (102) or (212)) that can be performed according to implementations of the present invention. In some implementations, the process (400) can be performed using one or more computer executable programs executed using one or more computing devices. For clarity of presentation, the description which follows generally describes the method (400) in the context of the other Figures in this description. It will be understood that the method (400) can be performed, for example, by any suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some implementations, several steps of the method (400) can be performed in parallel, in combination, in loops or in any order.
[00100] In the beginning, the process (400) can be implemented together with the system (100-300), as illustrated in Figures 1 to 3. In some implementations of the present invention, the trust protocol network (102) and / or (212) includes a main node (404) and one or more backup nodes (406). The trust protocol network (102) and / or (212) communicates with the computing system (106) and / or (108), such as client nodes (402) over the network (110) to provide trust protocol. Each of the client nodes (402), primary node (404) and backup node (406) can be a special purpose computer or other data processing device configured to perform the processes here
Petition 870190097362, of 09/30/2019, p. 40/134
33/91 discussed. For example, the client node (402) can also be referred to as a client terminal or a client device that interacts with a trusted protocol network. The client node (402) can install, for example, a client application or a client software development kit (SDK) in connection with the trust protocol network for access and communication with the trust protocol network. The primary node (404) and one or more backup nodes (406) can also be referred to as consensus nodes or network nodes that obtain consensus and record immutable information in the trust protocol network.
[00101] The process (400) starts at (408), in which the client node (402) generates a transaction request. In some implementations of the present invention, the transaction request may include a request requesting a trust protocol service from the trust protocol network (102) and / or (212).
[00102] In (410), the client node (402) sends the transaction request to the primary node (404) of the trust protocol network (102) and / or (212). In some implementations of the present invention, the primary node (404) assigns a sequence number to the transaction request to keep track of transaction requests after receiving the transaction request from the client node (402).
[00103] In (412), the primary node (404) generates a number of EC blocks after receiving the transaction request from the client node (402). In some implementations of the present invention, the primary node (404) generates the number of EC blocks according to an EC code using the transaction request. For example, referring to Figure 5, the primary node (404) applies an EC code (504) to a transaction request (502) and transforms the transaction request (502) into an EC message (506) using the code EC (504). The EC code (504) is an early error correction code
Petition 870190097362, of 09/30/2019, p. 41/134
34/91 (FEC) on the assumption of bit deletions. The EC code (504) transforms the original transaction request (502) into a longer EC message (506), such that the original transaction request (502) can be retrieved from a portion or fragment of the EC message (506).
[00104] In some implementations of the present description, the EC code (504) is an almost optimized erasure code, such as a Tornado code or a low density parity check code. In alternative implementations of the present invention, the EC code (504) is an almost optimal source code, such as a source code, an online code, a Luby transformation code (LT), or a raptor code. In alternative implementations of the present invention, the EC code (504) is an optimal erasure code, such as a parity code, a Parchive code, a Reed-Solomon code or a regeneration code. In some implementations of the present invention, the EC code (504) can be any suitable type of elimination code.
[00105] After transforming the transaction request (502) into the EC message (506), the primary node (404) generates a number of EC blocks (508) using the EC message (506). For example, as illustrated in Figure 5, the primary node (404) generates four EC blocks (508), EC block A, EC block B, EC block C and EC block dividing the EC message (506). Note that EC blocks (508) are illustrated in Figure 5 as including four blocks for illustrative purposes, EC blocks (508) can be generated as including any suitable number of EC blocks (508). EC blocks (508) will be sent to the respective backup nodes (406) within the INITIAL messages.
[00106] In some implementations of the present invention, EC blocks (508) are the same size. However, in alternative implementations, EC blocks (508) can be different sizes from each other.
Petition 870190097362, of 09/30/2019, p. 42/134
35/91 [00107] In some implementations of the present invention, the primary node (404) generates a hash tree (500) (for example, a Merkle tree) using EC blocks (508). The hash tree (500) includes a number of leaf nodes that are labeled with the hash of data blocks and a number of non-leaf nodes that are labeled with the cryptographic hash of the labels of their child nodes. For example, as illustrated in Figure 5, the hash tree (500) is configured to include four leaf nodes (510), hash A, hash B, hashC and hash D which are generated as a cryptographic hash of their respective EC blocks (508), four non-leaf nodes (512) that are generated as a hash of the concatenation of their respective child nodes (510), and a non-leaf node (514) that is generated as a hash of their child nodes (512 ) and is a root hash of the hash tree (500).
[00108] Hash trees (500) allow efficient verification and protect verification of the contents of large data structures. Hash trees (500) can be used to check any type of data stored, manipulated and transferred on and between computers. They can help ensure that data blocks received from other peers on a P2P network are received undamaged and unchanged, and even to verify that the other peers do not send false blocks. Checking data blocks using the hash tree (500) will be discussed below in more detail with reference to the following steps in the consensus process (400).
[00109] Referring again to Figure 4, the primary node (404) generates a first message (for example, an INITIAL message) after generating the EC blocks (508) and the hash tree (500). The first message indicates that the primary node is the beginning of a consensus process. In some implementations, the INITIAL message, as an example of the first message, is generated using the information in blocks EC (508) and
Petition 870190097362, of 09/30/2019, p. 43/134
36/91 in the hash tree (500). In some implementations of the present invention, referring to Figure 6, the INITIAL message has a format of <epoch, tx_root _ / As / , ec_block _ / As / , ec_block, seq, j>, where "epoch" represents a consensus round in which the message is being sent, “tx_root _ / as / ” represents the hash root (514) in hashish (500), “ec_block _ / as / ” represents the hashes (510) and / or (512) in the hash tree (500), “ec_block” represents the EC blocks (508) in the hash tree (500), “seq” represents the sequence number associated with the request transaction (502) and “j” represents the network node that generates and sends the INITIAL message. In some implementations, the INITIAL message may have a different format, for example, including additional or different fields.
[00110] Referring again to Figure 4, in (416), in the first phase of the consensus process, the primary node (404) multi-transmits the INITIAL message to the other network nodes (for example, copy nodes of security (406)). In some implementations, the INITIAL messages that are sent to the backup nodes (406) have a format of <epoch, tx_root_hash, ec_block _ / As / , ec_block, seq, j>. For example, the primary node (404) can send a first INITIAL message <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, block EC A, 1, 0> to a first backup node ( 406) and a second INITIAL message <epoch 1, Hash ABCD, {Hash A, Hash C, Hash D}, EC block B, 1, 0> to a second backup node (406), and so on. Note that information in the INITIAL message, such as “ec_block”, can be used with “ec_b ock_hash to reconstruct the hash tree (500). For example, in the first INITIAL message <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 0>, the EC block (508) “EC block A” can be divided to generate a cryptographic hash (510) “Hash A, which is later used with the other hashes (510)“ {Hash B, Hash C, Hash D} ”to reconstruct the hash tree (500). THE
Petition 870190097362, of 09/30/2019, p. 44/134
37/91 rebuilt hash tree (500) will be used to check ECHO messages, as discussed below, in greater detail with reference to the steps to follow in the consensus process.
[00111] In (418), each of the backup nodes (406) generates a second message (for example, an ECHO message) in the second phase of the consensus process after receiving the initial message from the primary node ( 404). The second message indicates that the backup node received the first message from the primary node. The second message is sent as a reply in response to the first message. In some implementations of the present invention, the ECHO message is generated by a backup node (406) as including the INITIAL message or a part of the INITIAL message and a signature of the backup node (406) associated with the INITIAL message. For example, the backup node (406) can generate the signature by signing the INITIAL message or a summary of the INITIAL message using a private key. The private key signature can be used by other network nodes using a public key paired with the private key to authenticate the ECHO message that includes the private key signature.
[00112] In some implementations of the present invention, referring to Figure 6, the ECHO message has a format of <epoch, tx_root_hash, ec_block _ / As / , ec_block, seq, sign_proof, j>, where "epoch" represents a consensus round in which the message is being sent, “tx_root _ / as / ” represents the hash root (514) in the hash tree (500), “ec_block _ / as / ” represents the hashes (510) and / or (512) in the hash tree (500), “ec_block” represents the EC blocks (508) in the hash tree (500) that are received by the respective backup nodes (406) , “Seq” represents the sequence number associated with the transaction request (502), “sign_proof” represents the signature of the backup nodes (406)
Petition 870190097362, of 09/30/2019, p. 45/134
38/91 associated with the INITIAL messages, and “j” represents the network node that generates and sends the ECHO message. In some implementations, the ECHO message may have a different format, for example, including additional or different fields.
[00113] Referring again to Figure 4, in (420), the backup nodes (406) send ECHO messages to the primary node (404). In (421), each of the backup nodes (406) sends the ECHO messages to the other backup nodes (406). At (423), each of the backup nodes (406) can receive ECHO messages from the other backup nodes (406).
[00114] In (422), the primary node (404) checks the ECHO messages that are sent by the backup nodes (406). In some implementations of the present invention, the primary node (404) checks whether the ECHO messages are valid according to the hash tree (500). For example, the primary node (404) can receive a first ECHO message <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 1> from a first backup node ( 406). The primary node (404) can retrieve the EC block (508) “EC block A” of the message and the hash to generate a cryptographic hash (510) “Hash A. The primary node (404) also uses the generated hash (510) “Hash A” with the other hashes (510) “{Hash B, Hash C, Hash D}” in the message to rebuild the hash tree (500). Then, the primary node (404) determines the root hash (514) of the reconstructed hash tree (500) and compares it with the root hash (514) in the ECHO message, as "Hash ABCD". If the two root hashes (514) match, the primary node (404) determines that the ECHO message is valid. The primary node (404) can store valid ECHO messages and discard ECHO messages that are considered invalid.
[00115] In (424), the primary node (404) determines whether a
Petition 870190097362, of 09/30/2019, p. 46/134
39/91 number of valid ECHO messages exceeds a predetermined threshold. In some implementations of the present invention, the primary node (404) determines whether the number of valid ECHO messages reaches a quorum number nf or 2f + 1, where n is the total number of network nodes and f is the maximum number of nodes in failure that the network can tolerate.
[00116] In (426), the primary node (404) reconstructs the transaction request (502) in response to the determination that the number of valid ECHO messages reaches the quorum number. In some implementations of the present invention, the primary node (404) reconstructs the transaction request (502) based on at least a subset of valid ECHO messages according to the EC code. For example, the primary node (404) can retrieve a number of n - 2f or f + 1 from the EC blocks (508) that are in the quorum number (for example, nf or 2f + 1) of valid ECHO messages, and use the recovered EC blocks (508) to reconstruct the transaction request (502) according to the EC code (504).
[00117] In (428), in the third phase of the consensus process, the primary node (404) generates a third message (for example, an ACCPET message) in response to the determination that the transaction request (502) has been reconstructed with success. The third message indicates that a network node has accepted a predetermined number of second messages. In some implementations, the third message may indicate that the network node is ready to perform the transaction. In some implementations, the third message may indicate that the transaction has been successfully rebuilt on the network node. For example, the ACCPET message can be used to indicate to other network nodes that the transaction request (502) has been successfully reconstructed. If the primary node (404) fails to rebuild the transaction request (502), the primary node (404) may not generate the ACCEPT message.
Petition 870190097362, of 09/30/2019, p. 47/134
40/91 [00118] In some implementations of the present invention, referring to Figure 6, the ACCEPT message has a format of <epoch, tx_root_hash, seq, sign_proofs, j>, where “epoch” represents a round of consensus in which the message is being sent, “tx_root _ / as / ” represents the hash root (514) in the hash tree (500), “seq” represents the sequence number associated with the transaction request (502), “sign_proofs” represents a set of signatures on valid ECHO messages and “j” represents the network node that generates and sends the ACCEPT message. In some implementations, the ACCEPT message may have a different format, for example, including additional or different fields.
[00119] Referring again to Figure 4, in (430), the main node (404) sends the ACCPET message to the backup nodes (406).
[00120] Similar to the primary node (404), each of the backup nodes (406) can reconstruct the transaction request, for example, by performing steps similar to the steps (422-428) as the primary node (404). At (432), each of the backup nodes (406) generates an ACCEPT message in response to the determination that the transaction request (502) has been successfully reconstructed by the backup node (406). In some implementations, the primary node (404) and the backup node (406) can perform steps (422-428) in a parallel manner, for example, as shown in Figure 3.
[00121] In (434), the backup nodes (406) send the ACCEPT messages to the primary node (404). However, each of the backup nodes (406) can send ACCEPT messages to the other backup nodes (406).
[00122] In (436), the primary node (404) performs the transaction request (502) in response to the determination that a number of
Petition 870190097362, of 09/30/2019, p. 48/134
41/91 ACCEPT messages exceed a predetermined threshold. In some implementations of the present invention, the primary node (404) determines whether the received ACCEPT messages are identical and whether a number of identical ACCEPT messages reaches a quorum number (for example, 2f + 1). If the number of identical ACCEPT messages reaches the quorum number, the primary node (404) determines that a consensus has been reached between all network nodes and then executes the transaction request (502) locally. In some implementations of the present invention, if the primary node (404) determines the number of identical ACCEPT messages does not reach the quorum number, the primary node (404) determines that a consensus has not been reached between all network nodes and, in then avoids executing the transaction request (502).
[00123] In some implementations of the present invention, each of the backup nodes (406) can perform the same operations that are performed by the primary node (404), as described above in (436), before executing the backup request. transaction (502). If a backup node (406) determines that the ACCEPT messages that have been received exceed a predetermined threshold, the backup node (406) determines that a consensus has been reached between the network nodes and executes the transaction request ( 502) locally. In some implementations of the present invention, if the backup node (406) determines that the number of identical ACCEPT messages does not reach the quorum number, the backup node (406) determines that a consensus has not been reached among all network nodes and then avoids executing the transaction request (502).
[00124] In (438), the main node (404) sends a transaction result to the client node (402) after executing the transaction request (502). The backup nodes (406) that successfully ran the
Petition 870190097362, of 09/30/2019, p. 49/134
42/91 transaction request (502) locally can also send their respective transaction results to the client node (402).
[00125] The consensus process, as discussed above, includes many features that improve the operation of the entire trust protocol system and help to alleviate the network bottleneck. For example, the consensus process in the present invention includes generating a number of EC blocks according to an EC code using a transaction request and sending one of the EC blocks to each of the network nodes. The EC block is smaller in size than the original transaction request. Therefore, sending the EC block instead of the transaction request to the network nodes reduces the size of the data blocks that are transmitted between the network nodes of the trust protocol network, thereby conserving the network bandwidth and reducing the network bandwidth. the network load. This further reduces the size of the data that is written to and read from the memory space of the network nodes, thereby reducing the load on the memory space of the network nodes and improving the efficiency of the generally trusted protocol system.
[00126] During the consensus process, the backup nodes are waiting for a request from the primary node. However, the primary node may encounter a Byzantine fault or a locking fault so that the primary node cannot transmit the request within a predetermined time window. When a specific amount of time has passed without the primary multi-transmission of the request, a new primary node may need to be chosen to prevent backup nodes from waiting indefinitely for requests to be executed.
[00127] Figure 7 represents an example of a process (700) for making a change to a primary node (for example, node (214) or (404)) of a distributed system (for example, trust protocol network ( 102 and 212)) that can be performed in accordance with
Petition 870190097362, of 09/30/2019, p. 50/134
43/91 the present invention. Specifically, Figure 7 illustrates a diagram showing an exemplary embodiment of a method (700) for effecting a change in a primary node, in accordance with the present invention. In some implementations, a primary node is associated with an age that includes a consensus process with the primary node being the leader. A change to a primary node can result in a time change.
[00128] In some implementations, in response to the determination that a primary node of a current era needs to be changed, a backup node of the trust protocol network sends a first message to the other network nodes. The first message indicates that the backup node would like to be a new primary node in a new era. For example, as illustrated in Figure 7, the backup node Ro sends an EPOCH_CHANGE message to the other network nodes Ri, R2 and Rana trust protocol network in response where the backup node Ro determines that a node current primary is defective and that a time change needs to be performed. The EPOCH_CHANGE message is an example of the first message indicating that backup node Ro applies as the new primary node. Epoch change can cause a change from a current epoch with a current primary node to a new epoch with a new primary node. Note that the process (700) is illustrated as implemented in conjunction with four network nodes for illustrative purposes only. The process (700) can be implemented in conjunction with any suitable number of network nodes.
[00129] Then, each of the network nodes receives the first message that is sent by the backup node, prepares a second message in response to the first message and multistreams the second message to the other network nodes. For example, as illustrated in Figure 7, network node Ri receives the message
Petition 870190097362, of 09/30/2019, p. 51/134
44/91
EPOCH_CHANGE which is sent by the backup node Ro, and replies to the backup node Rocom a NEW_EPOCH message indicating an acknowledgment that the backup node Ro may become the new primary node. Meanwhile, Ri's network node also broadcasts the NEW_EPOCH message to other network nodes, such as network nodes R ₂ and R3. Likewise, the network node R ₂ and R ₃ each transmit a NEW_EPOCH message to the other network nodes.
[00130] The epoch change process as discussed above, an EPOCH_CHANGE message format, and a NEW_EPOCH message format will be discussed in more detail below with reference to Figures 8 and 9.
[00131] Figure 8 illustrates an example of a process (800) for making a change to a primary node in a distributed system (for example, trust protocol network (102) or (212)) that can be performed accordingly with implementations of the present invention. In some implementations, the example process (800) can be performed using one or more computer executable programs executed using one or more computing devices. For clarity of presentation, the following description generally describes the method (800) in the context of the other Figures in this description. It will be understood that the method (800) can be performed, for example, by any suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some implementations, several steps of the method (800) can be performed in parallel, in combination, in loops or in any order.
[00132] The process (800) starts at (806), where a backup node (802) determines that a time change needs to be performed. The time change discussed here causes a change to a
Petition 870190097362, of 09/30/2019, p. 52/134
45/91 current epoch with a current primary node to a new epoch with a new primary node. An exemplary time may include a consensus process (for example, consensus process (300) or (400)) to achieve consensus between a number of network nodes using a primary node as discussed above with reference to Figures 3 to 6.
[00133] In some implementations of the present invention, the backup node (802) determines that an epoch change needs to be performed in response to the determination that the backup node (802) is still waiting for a request from the node current primary after a specific amount of time has passed without receiving the request from the current primary node. For example, the current primary node may encounter a Byzantine fault or a locking fault, so that the current primary node cannot multi-transmit the request within a predetermined time window. Therefore, the epoch change is triggered by threshold times that prevent backup nodes from waiting indefinitely for requests to be performed. The epoch change process discussed here provides liveliness and reduces network latency, allowing the system to progress when the primary node fails.
[00134] In (808), the backup node (802) determines a respective weight of the backup node (802) associated with each of the phases of the consensus process at the current time. In some implementations, the consensus process includes three phases as described above with reference to Figures 3 to 6 Weight is a metric for a qualification of the backup node (802) to be the new primary node in a new era.
[00135] In some implementations of the present invention, the backup node (802) determines a weight of the backup node (802) for a first phase of the consensus process at the time
Petition 870190097362, of 09/30/2019, p. 53/134
46/91 current as a first value. For example, the backup node (802) can receive an initial weight of 10% if the backup node (802) has entered a first phase of the consensus process (for example, the first phase (310) consensus process (300)). In alternative implementations of the present invention, the backup node (802) can assign any appropriate weight value to the backup node (802) for the first phase of the current consensus process.
[00136] In some implementations of the present invention, the backup node (802) determines a weight of the backup node (802) for a second stage of the consensus process (for example, the second stage (320) of the consensus process (300)) at the current time based on a quorum verification process. The quorum verification process is carried out by determining whether the backup node (802) receives a predetermined number (for example, 2f + 1) of ECHO messages from the other network nodes in the second phase of the consensus process.
[00137] In some implementations of the present invention, if the backup node (802) fails to verify the quorum (for example, the backup node (802) receives a number of ECHO messages that is less than a threshold predetermined), the backup node (802) can determine the weight of the backup node (802) for the second stage of the consensus process as a first value. If the backup node (802) passes the quorum check (for example, the backup node (802) receives a number of ECHO messages that equals or exceeds a predetermined threshold), the backup node ( 802) can determine the weight of the backup node (802) for the second stage of the consensus process is a second value. In some implementations of the present invention, the second value is determined to be greater than the first value. For example, if the backup node (802)
Petition 870190097362, of 09/30/2019, p. 54/134
47/91 fails to verify the quorum, the backup node (802) can be assigned a zero weight value for the second phase of the consensus process. If the backup node (802) passes the quorum check, the backup node (802) can be assigned a weight value of 45% for the backup node (802) of the second stage of the process consensus. However, in alternative implementations of the present invention, the backup node (802) can assign any suitable value to the backup node (802) for the second phase of the consensus process at the present time.
[00138] In some implementations of this description, the quorum check also includes verifying whether the ECHO messages that the backup node (802) receives from the other nodes in the network during the second phase of the consensus process are valid. For example, the backup node (802) can authenticate private key signatures on ECHO messages using a public key to determine whether ECHO messages are valid.
[00139] Similar to determining the weight for the second phase, in some implementations, the backup node (802) determines a weight of the backup node (802) for a third phase of the consensus process (for example, the third phase (330) of the consensus process (300)) at the current time based on a quorum verification process. The quorum verification process is carried out by determining whether the backup node (802) receives a predetermined number (for example, 2f + 1) of acceptance messages from the other network nodes in the third phase of the consensus process at the current time . Each acceptance message from other network nodes indicates that each of the other network nodes accepted a predetermined number of ECHO messages. The acceptance message can be, for example, the ACCEPT messages
Petition 870190097362, of 09/30/2019, p. 55/134
48/91 described above with reference to the third stage (330) of the consensus process (300).
[00140] In some implementations of the present invention, if the backup node (802) fails to check the quorum (for example, the backup node (802) receives a number of ACCEPT messages that is less than a threshold predetermined), the backup node (802) can determine the weight of the backup node (802) for the third stage of the consensus process as a first value. If the backup node (802) passes the quorum check (for example, the backup node (802) receives a number of ACCEPT messages that equals or exceeds a predetermined threshold), the backup node ( 802) can determine the weight of the backup node (802) for the third stage of the consensus process as a second value. In some implementations, the second value is determined to be greater than the first value. For example, if the backup node (802) fails the quorum check, the backup node (802) can assign a zero weight value to the backup node (802) of the third stage of the process consensus. If the backup node (802) passes the quorum check, the backup node (802) can assign a weight value of 45% to the backup node (802) of the third stage of the process consensus. However, in alternative implementations of the present invention, the backup node (802) can assign any suitable value to the backup node (802) for the third stage of the consensus process at the present time.
[00141] In (810), after determining the respective backup node weights (802) for the phases of the consensus process at the current time, the backup node (802) determines a sum of node weight backup (802) for the backup process
Petition 870190097362, of 09/30/2019, p. 56/134
49/91 consensus based on the respective weights. In some implementations of the present invention, the weight sum is a sum of the respective sums of the backup nodes associated with each of the phases of the consensus process at the present time. For example, if the backup node (802) determined a first backup node weight value (802) for the first phase to be 10%, a second backup node weight value (802 ) for the second phase will be 45% and a third weight value of the backup node (802) for the third phase will be 45%, the backup node (802) will determine the weight sum as being 100%. As another example, if the backup node (802) determined a first weight value of the backup node (802) for the first phase to be 10%, a second weight value of the backup node ( 802) for the second phase as being 45% and a third weight value of the backup node (802) for the third phase as being 0, the backup node (802) determines the weight sum as being 55%.
[00142] In (812), the backup node (802) sends an EPOCH_CHANGE message to the other network nodes (804) if the backup node (802) determines that the weight sum that was determined in (810) reaches or exceeds a predetermined threshold. For example, the backup node (802) can send an EPOCH_CHANGE message to the other network nodes (804) if the weight sum as determined in (810) reaches 100%. The EPOCH_CHANGE message indicates a request for a change from the current epoch with the current primary node to the new epoch, with the backup node being the new primary node.
[00143] In some implementations of the present invention, referring to Figure 9, the message EPOCH_CHANGE has a format of <weight, epoch + 1, ECHO {}, ACCEPT {}, j>, where "weight" represents the sum
Petition 870190097362, of 09/30/2019, p. 57/134
50/91 weight of the backup node (802) as previously determined in (810) for the consensus process, “ppoch + 1” represents a round of new consensus (that is, a new era) associated with a new primary node, “ECHO {}” represents a set of ECHO messages that the backup node (802) receives during the second phase of the consensus process, “ACCEPT {}” represents a set of ACCEPT messages that the copy node security (802) receives during the third phase of the consensus process, and “j” represents the network node (for example, backup node (802)) that generates and sends the EPOCH_CHANGE message. In some implementations, the EPOCH_CHANGE message may have a different format, for example, including additional or different fields.
[00144] Referring again to Figure 8, in (814), the network nodes (804) other than the backup node (802) check the EPOCH_CHANGE message sent by the backup node (802). In some implementations, each of the network nodes (804) checks whether the EPOCH_CHANGE message is valid by checking whether the weight sum in the EPOCH_CHANGE message is valid. In some implementations, verifying that the weight sum in the EPOCH_CHANGE message is valid includes verifying that the signature set in the ECHO messages included in the EPOCH_CHANGE message is valid. For example, each of the network nodes (804) can authenticate the set of private key signatures on ECHO messages including the EPOCH_CHANGE message using a public key.
[00145] In (816), each of the network nodes (804) sends a NEW_EPOCH message to the backup node (802) in response to the verification that the EPOCH_CHANGE message sent by the backup node (802) is valid. The NEW_EPOCH message indicates a confirmation that the backup node is the new primary node. For example, the NEW_EPOCH message sent by a network node (804) includes
Petition 870190097362, of 09/30/2019, p. 58/134
51/91 an indication that the network node (804) recognizes that the backup node (802) will become the new primary node in the new era. In the meantime, each of the network nodes (804) also sends the NEW_EPOCH message to the other network nodes (804).
[00146] Referring to Figure 9, the message NEW_EPOCH is generated as having a format of <epoch + 1, i, j, seq, ec_digest>, where “epoch + 1” represents a new consensus round (that is, a new epoch) associated with a new primary node, “i” represents the new primary node in the new epoch, “j” represents a network node (804) that sends the message NEW_EPOCH and “ec_digest” represents a summary of the EPOCH_CHANGE message. In some implementations, the EPOCH_CHANGE message digest includes a hash value from the EPOCH_CHANGE message. In some implementations, the NEW_EPOCH message may have a different format, for example, including additional or different fields.
[00147] Referring again to Figure 8, in (818), the backup node (802) checks if the NEW_EPOCH messages that are sent by the network nodes (804) are valid. In some implementations, the backup node (802) checks for NEW_EPOCH messages, checking that the EPOCH_CHANGE message digest in NEW_EPOCH messages is valid. Because the summary includes information from the EPOCH_CHANGE message, the summary also includes signatures in the EPOCH_CHANGE message. The backup node (802) can check the EPOCH_CHANGE message digest, verifying that the signature set in the EPOCH_CHANGE message is valid.
[00148] In (820), the backup node (802) determines whether a valid NEW_EPOCH message number as determined in (818) exceeds a predetermined threshold. In some implementations, the predetermined threshold is a quorum number (for example,
Petition 870190097362, of 09/30/2019, p. 59/134
52/91 (example, 2f + 1).
[00149] At (822), the backup node (802) determines that the backup node (802) is the new primary node in the new era in response to the determination that the message number NEW_EPOCH is valid as determined exceeds the predetermined threshold. Note that each of the network nodes (804) performs the same steps (818822) as the backup node (802), and the network nodes (804) and the backup node (802) can perform steps (818-822) in a parallel manner. For example, each of the network nodes (804) can check a set of NEW_EPOCH messages sent from other network nodes (804), determine whether a number of valid NEW_EPOCH messages exceeds a predetermined threshold, and determine a new primary node.
[00150] The time change process (for example, process (700) or (800)), as discussed above, includes many features that improve the operation of the entire trust protocol system and help to alleviate the network bottleneck . For example, the time change process in the present invention includes assigning respective weights to the three phases of the consensus process, determining a weight sum based on the respective weights of the three phases, and determining a new primary node based on the weight sum. The epoch change process based on the sum of weight instead of a round robin method can facilitate the choice of a new primary node that is not defective in a timely manner. A round robin method can cause a frequent change of the primary node when several network nodes in the line for the new primary node are defective. This significantly affects the trust protocol service, introducing latency or delay in locating a primary node without failure. Unlike the round robin method, the time-change process in the current invention depends on the weight sum to select the new primary node, which can reduce the time
Petition 870190097362, of 09/30/2019, p. 60/134
53/91 in the location of the new primary node that is not defective. This can further improve the efficiency of the general trust protocol system in providing trust protocol services.
[00151] During the operation of a trusted protocol network, the execution speed of some network nodes may lag behind most network nodes due to network jittering, sudden power failure, disk failure and the like. In this scenario, more than 1/3 of the network nodes in the system may fail. BFT provides security and liveliness if less than 1/3 of the network nodes fail during the life of the system. However, these guarantees are insufficient for long-lived systems because the upper threshold is likely to be exceeded in the scenario described above. Therefore, a recovery process is desirable that will cause faulty network nodes to behave correctly again and continue to participate in subsequent consensus processes to allow the system to tolerate more than f failures during its lifetime. In addition, the recovery process described can recover one or more network nodes that are still running a consensus process (for example, the consensus process (300) or (400)) and do not have to wait until consensus is reached between all network nodes. As such, the recovery process described can further reduce system latency and improve the efficiency of the trusted protocol network.
[00152] Figure 10 illustrates an example of a process (1000) to perform a recovery process of a network node (for example, node (214) or (404)) of a distributed system (for example, protocol network (102 and 212)) that can be performed according to implementations of the present invention. Specifically, Figure 10 illustrates a diagram showing an exemplary embodiment of a method (1000) of performing a network node recovery process, from
Petition 870190097362, of 09/30/2019, p. 61/134
54/91 according to the present invention. As illustrated in Figure 10, the process (1000) includes some phases and steps.
[00153] In a first phase (1010), a network node (for example, Ro network node) that would like to retrieve a target transaction with a multi-target Ro sequence number transmits a status request message (for example , QUERY_STATE message) for the other network nodes indicating that the network node must be recovered. The status request message may include the target sequence number that the network node Ro would like to retrieve. In a second phase (1020), the other network nodes receive the status request message and send a status response message (for example, REPLY_STATE message) to the network node Ro. In a third phase (1030), network node Ro sends a request message (for example, message FETCH_ECHO) to the other network nodes requesting an ECHO message from each of the other network nodes. The ECHO message can be the same ECHO message sent by the respective network nodes in the second phase (320) of the consensus process (300) as described above with reference to Figures 3 to 6. In a fourth phase (1040), each of the others network nodes sends an ECHO message to network node Ro in response to the FETCH_ECHO message. In a fifth phase (1050), the network node Ro checks the ECHO messages and retrieves the target transaction according to an EC code, for example, according to the exemplary reconstruction techniques as described above with reference to Figure 4. In a sixth phase (1060), the network node Ro sends an ACCEPT message to the other network nodes, indicating that the network node has been recovered.
[00154] Note that the process (1000) is illustrated as implemented in conjunction with four network nodes for illustrative purposes only. The process (1000) can be implemented in conjunction with any suitable number of network nodes. The process (1000), a format of the
Petition 870190097362, of 09/30/2019, p. 62/134
55/91 message QUERY_STATE and a format of message REPLY_STATE will be discussed below in greater detail with reference to Figures 11 and 12.
[00155] Figure 11 illustrates an example of a process (1100) to perform a recovery process of a network node in a distribution system (for example, trust protocol network (102) or (212)) that can be performed according to implementations of the present invention. In some implementations, the process (1100) can be performed using one or more executable programs per computer executed using one or more computing devices. For clarity of presentation, the description that follows generally describes method (1100) in the context of the other Figures in this description. It will be understood that method (1100) can be performed, for example, by any suitable system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some implementations, several steps of the method (1100) can be performed in parallel, in combination, in loops or in any order.
[00156] The process (1100) starts at (1106), where a network node (1102) multi-transmits a status request message to the other network nodes (1104). The status request message includes an indication that the network node (1102) is about to retrieve a target transaction with a target sequence number. The network node (1102) can be a primary node or a backup node.
[00157] In some implementations of the present invention, referring to Figure 12, the QUERY_STATE message, as an example of the status request message, has a format of <j, seq>, where “j” represents a node network (1102) that sends the QUERY_STATE message and “seq” represents a higher sequence number or a more recent sequence number for network node (1102) in the current consensus process. In
Petition 870190097362, of 09/30/2019, p. 63/134
56/91 In some implementations, the QUERY_STATE message may have a different format, for example, including additional or different fields.
[00158] By transmitting the QUERY_STATE message to the other network nodes (1104), the network node (1102) is asking the other network nodes (1104) to send their most recent sequence number to the network node (1102) ), thus obtaining the most recent block information from the trust protocol system. And by obtaining the most recent block information from the entire trust protocol system, the network node (1102) may be able to synchronize with the most recent state of the entire system, thus recovering and continuing to participate in the consensus process .
[00159] Referring again to Figure 11, at (1108), each of the other network nodes (1104) sends a status response message (for example, REPLY_STATE message) to the network node (1102) in response upon receipt of the status request message. In some implementations, the status response message includes a previous sequence number associated with the network nodes (1104).
[00160] In some implementations, referring to Figure 12, the REPLY_STATE message, as an example of the status reply message, has a format of <j, last_seq>, where “j” represents a network node (1104) which sends the message REPLY_STATE and “last_seq” represents a previous sequence number for the network node (1104) in the current consensus process. In some implementations, the REPLY_STATE message may have a different format, for example, including additional or different fields.
[00161] Referring again to Figure 11, at (1110), the network node (1102) determines whether a number of received status response messages exceeds a predetermined threshold. For example, the network node (1102) can determine whether a number of REPLY_STATE messages
Petition 870190097362, of 09/30/2019, p. 64/134
57/91 received exceeds a quorum number (for example, 2f + 1 or n-f). In some implementations, the network node (1102) further determines whether the quorum number of the received REPLY_STATE messages includes an identical sequence number. The quorum number of REPLY_STATE messages received including an identical sequence number means that most network nodes (1104) agree on a common system-wide state.
[00162] In (1112), the network node (1102) determines the target sequence number based on an identical sequence number if the network node (1102) determines that the number of status response messages including the number identical sequence received from the network nodes (1104) exceeds the predetermined threshold. For example, the network node (1102) can determine that the target sequence number is an increment (for example, “last_seq + 1”) of the same sequence number (for example, “last_seq”).
[00163] In (1114), the network node (1102) sends a request message (for example, message FETCH_ECHO) to the other network nodes (1104). The FETCH_ECHO message is sent by the network node (1102) to request an ECHO message from each of the other network nodes (1104). As discussed above with reference to Figures 3 to 6, the ECHO message is a message transmitted by the network nodes (1104) to obtain consensus between the network nodes (1104) in a target transaction. The ECHO message includes a part of the target transaction (for example, an EC block) and a signature from the network node (1104) that sends the ECHO message.
[00164] In some implementations, referring to Figure 12, the message FETCH_ECHO, as an example of the request message, has a format of <j, last_seq + 1>, where “j” represents a network node (1102) which sends the message FETCH_ECHO and “last_seq + 1” represents a target sequence number associated with the ECHO messages that the
Petition 870190097362, of 09/30/2019, p. 65/134
58/91 network (1102) is requesting other network nodes (1104). In some implementations, the FETCH_ECHO message may have a different format, for example, including additional or different fields.
[00165] The FETCH_ECHO message as discussed here is sent by the network node (1102) to request ECHO messages including a more recent sequence number or a greater sequence number from the other network nodes (1104). By collecting ECHO messages including a more recent sequence number or a greater sequence number of the other network nodes (1104), the network node (1102) may be able to recover to the most recent state associated with the most recent sequence number.
[00166] Referring again to Figure 11, in (1116), each of the network nodes (1104) sends an ECHO message to the network node (1102) in response to receiving the message FETCH_ECHO. In some implementations, each of the network nodes (1104) checks the FETCH_ECHO message before sending the ECHO message to the network node (1102). In some implementations, each of the network nodes (1104) checks for the FETCH_ECHO message by determining whether the sequence number included in the FETCH_ECHO messages exceeds a more recent sequence number associated with the network node (1104). If the sequence number included in the FETCH_ECHO messages is the same as the most recent sequence number associated with the network node (1104), the network node (1104) determines that the FETCH_ECHO message is valid and an ECHO message will be sent to the network node. network (1102). If the sequence number included in the FETCH_ECHO messages exceeds the most recent sequence number associated with the network node (1104), the network node (1104) determines that the FETCH_ECHO message is invalid and that an ECHO message will not be sent to the node network (1102).
[00167] In (1118), the network node (1102) checks whether the
Petition 870190097362, of 09/30/2019, p. 66/134
59/91 ECHO messages sent by the network nodes (1104) are valid. In some implementations, the network node (1102) checks for ECHO messages using a Merkel tree. For example, the network node (1102) can use the data included in the ECHO message to reconstruct a Merkel tree and determine a reconstructed root hash value from the reconstructed Merkel tree. The network node (1102) can then compare the reconstructed root hash value with a root hash value included in the ECHO message. If the hash value of the reconstructed root matches the hash value of the root included in the ECHO message, the network node (1102) will determine that the ECHO message is valid. If the reconstructed root hash value does not match the root hash value included in the ECHO message, the network node (1102) determines that the ECHO message is invalid and can discard the invalid ECHO message.
[00168] In some implementations, the network node (1102) verifies that the ECHO message is valid, checking also if the signature in the ECHO message is valid. For example, the network node (1102) can authenticate the private key signature in the ECHO message using a public key paired with the private key to verify the signature.
[00169] In (1120), the network node (1102) determines whether a number of valid ECHO messages received from the other network nodes (1104) exceeds a predetermined threshold. For example, the network node (1102) can determine whether a number of valid ECHO messages received from other network nodes (1104) exceeds a quorum number (for example, 2f + 1).
[00170] In (1122), the network node (1102) retrieves the target transaction with the target sequence number in response to the determination that the number of valid ECHO messages exceeds the predetermined threshold. In some implementations, the network node (1102) retrieves the target transaction using the data included in the number of ECHO messages
Petition 870190097362, of 09/30/2019, p. 67/134
60/91 valid. For example, the network node (1102) can retrieve a subset of EC blocks included in the ECHO messages to reconstruct the target transaction according to an EC code.
[00171] In (1124), the network node (1102) sends an ACCEPT message to the other network nodes (1104) after retrieving the target transaction. For example, network node (1102) can multistream an ACCEPT message to other network nodes (1104) after successfully reconstructing the target transaction. In some implementations, the ACCEPT message includes a set of signatures on the ECHO messages and the target sequence number. When sending the ACCEPT message including signatures and the target sequence number to the other network nodes (1104), the network node (1102) indicates to the other network nodes (1104) that the network node (1102) has recovered and synchronized with the most recent system state.
[00172] The recovery process, as discussed above in the present invention, includes many features that improve the operation of computers that implement the recovery process and help to alleviate the network bottleneck. For example, the recovery process in the present invention includes operations including sending a status request message through a network node that applies to being a new primary node, receiving status response messages from the other network nodes and sending a message FETCH_ECHO by the network node to request ECHO messages from the other network nodes. These operations are performed in such a way that the failed network node recovery process does not interfere with the normal operation of the consensus process among the other non-defective network nodes. This facilitates the conservation of computing and network characteristics to recover the failed network node, reducing the complexity of the recovery process.
Petition 870190097362, of 09/30/2019, p. 68/134
61/91 [00173] Referring to Figure 13, Figure 13 is a diagram illustrating modules of a consensus apparatus (1300), according to an implementation of the present invention. The consensus apparatus (1300) can be applied to a consensus system based on reliable protocol technology. For example, the device (1300) can correspond to the implementations shown in Figures 1 to 6. The device (1300) can be implemented on a primary node in the trust protocol network. The apparatus (1300) includes the following: a receiving or receiving unit (1302), configured to receive a transaction request; a generating unit (1304), configured to generate a number of erase code (EC) blocks according to an EC code using the transaction request; a transmitter or transmission unit (1306), configured to send a number of first messages to one or more backup nodes, respectively, wherein each number of first messages includes a composite hash value associated with the number of EC blocks; the receiver or receiving unit (1302), further configured to receive at least a second message from at least one of the backup nodes, the at least one second message including one of the number of first messages and a signature of at least at least one of the backup nodes associated with the number of the first number of messages; a verification unit (1308), configured to verify that at least one second message is valid in response to receiving at least one second message from at least one of the backup node; a determination unit (1310), configured to determine whether a number of second valid messages exceeds a predetermined threshold; a reconstruction unit (1312), configured to reconstruct the transaction request based on a subset of the number of second valid messages according to the EC code in response to
Petition 870190097362, of 09/30/2019, p. 69/134
62/91 determination that the number of valid second messages exceeds the predetermined threshold; the transmitter or transmission unit (1306), additionally configured to send a third message, to the other network nodes in response to the determination that the transaction request has been successfully reconstructed, in which the third message includes a signature set that are in the second valid messages; the receiver or the receiving unit (1302), further configured to receive at least a third message from at least one of the backup nodes; and an execution unit (1314), configured to execute the transaction request in response to receiving a predetermined number of third messages that are identical.
[00174] In an optional implementation, the transaction request is associated with a sequence number.
[00175] In an optional implementation, the generation of the plurality of EC blocks according to an EC code includes the following: transforming the transaction request into an EC message using the EC code and dividing the EC message into the EC block number.
[00176] In an optional implementation, the hash value composed of the number of EC blocks is generated using a hash tree.
[00177] In an optional implementation, the hash tree includes a Merkle tree and where the compound hash value is a root hash value of the Merkle tree.
[00178] In an optional implementation, the signature of at least one of the backup nodes associated with one of the number of first messages includes a private key signature of at least one of the backup nodes associated with the number of first messages .
[00179] In an optional implementation, at least
Petition 870190097362, of 09/30/2019, p. 70/134
63/91 a second message also includes at least one of the number of EC blocks.
[00180] In an optional implementation, checking whether the at least one second message is valid includes the following: generating a reconstructed hash tree using at least one of the number of EC blocks in at least one second message; determining a reconstructed composite hash value from the reconstructed hash tree; and determining whether the reconstructed composite hash value matches the composite hash values in at least a second message.
[00181] In an optional implementation, the determination unit (1310) is further configured to determine that at least a second message is valid in response to the determination that the reconstructed composite hash value matches the composite hash values in the second messages .
[00182] In an optional implementation, the predetermined number of third identical messages includes the predetermined number of third messages with an identical set of signatures.
[00183] Figure 13 is a schematic diagram illustrating an internal functional module and a structure of a consensus device (1300). An execution body, in essence, can be an electronic device, and the electronic device includes the following: at least one processor; and a memory configured to store an executable instruction from at least one processor.
[00184] The at least one processor is configured to receive a transaction request; generate a number of elimination code (EC) blocks according to an EC code using the transaction request; send a number of first messages to one or more backup nodes, respectively, where each number of first
Petition 870190097362, of 09/30/2019, p. 71/134
64/91 messages include a composite hash value associated with the number of EC blocks; receive at least a second message from at least one of the backup nodes, where the at least one second message includes one of the number of first messages and a signature of at least one of the backup nodes associated with the number of first posts; verify that at least one second message is valid in response to receiving at least one second message from at least one of the backup node; determining whether a number of valid second messages exceeds a predetermined threshold; reconstruct the transaction request based on a subset of the number of second valid messages according to the EC code, in response to the determination that the number of second valid messages exceeds the predetermined threshold; send a third message to the other network nodes in response to the determination that the transaction request has been successfully rebuilt, where the third message includes a set of signatures that are in the second valid messages; receive at least a third message from at least one of the backup nodes; and executing the transaction request in response to receiving a predetermined number of third identical messages.
[00185] Optionally, the transaction request is associated with a sequence number.
[00186] Optionally, the generation of the plurality of EC blocks according to an EC code includes the following: transforming the transaction request into an EC message using the EC code and dividing the EC message into the EC block number.
[00187] Optionally, the hash value composed of the number of EC blocks is generated using a hash tree.
[00188] Optionally, the hash tree includes a tree
Petition 870190097362, of 09/30/2019, p. 72/134
65/91
Merkle, and where the compound hash value is a root hash value of the Merkle tree.
[00189] Optionally, the signature of at least one of the backup nodes associated with one of the number of first messages includes a private key signature of at least one of the backup nodes associated with one of the number of first messages.
[00190] Optionally, at least a second message also includes at least one of the number of EC blocks.
[00191] Optionally, checking whether the at least one second message is valid includes the following: generating a reconstructed hash tree using at least one of the number of EC blocks in at least one second message; determining a reconstructed composite hash value from the reconstructed hash tree; and determining whether the reconstructed composite hash value matches the composite hash values in at least one second message.
[00192] Optionally, the at least one processor is further configured to determine that the at least one second message is valid in response to the determination that the reconstructed composite hash value corresponds to the composite hash values in the second messages.
[00193] Optionally, the predetermined number of third identical messages includes the predetermined number of third messages with an identical set of signatures.
[00194] Referring to Figure 14, Figure 14 is a diagram illustrating modules of a consensus apparatus (1400), according to an implementation of the present invention. The device (1400) for obtaining consensus can be applied to a consensus system based on a reliable protocol technology. The device (1400) can correspond to the
Petition 870190097362, of 09/30/2019, p. 73/134
66/91 implementations shown in Figures 1 to 6. For example, the apparatus (1400) can be implemented in a backup node of a trusted protocol network. The apparatus (1400) includes the following: a receiving or receiving unit (1402), configured to receive a first message from the primary node, wherein the first message includes a composite hash value associated with a number of EC blocks, where the number of EC blocks is generated by the primary node according to an EC code using a transaction request; a transmitter or transmission unit (1404), configured to send, via the backup node, a second message to the other network nodes in response to receiving the first message, where the second message includes the first message and a signature the backup node associated with the first message; the receiver or receiving unit (1402), further configured to receive at least a second message from at least one backup node other than the backup node; a verification unit (1406), configured to verify that at least a second message is valid in response to receiving at least a second message from at least one backup node; a determination unit (1408), configured to determine whether a number of second valid messages exceeds a predetermined threshold; a reconstruction unit (1410), configured to reconstruct the transaction request based on a subset of the number of second valid messages according to the EC code in response to the determination that the number of second valid messages exceeds the predetermined threshold; the transmitter or transmission unit (1404), configured to send a third message to the other network nodes in response to the determination that the transaction request has been successfully reconstructed, wherein the third message includes a set of signatures that are in the second valid messages; O
Petition 870190097362, of 09/30/2019, p. 74/134
67/91 receiver or receiving unit (1402), still configured to receive at least a third message from at least one of the backup nodes; and an execution unit (1412), configured to execute the transaction request in response to receiving a predetermined number of third messages that are identical.
[00195] In an optional implementation, the generation of the plurality of EC blocks according to an EC code includes the following: transform the transaction request into an EC message using the EC code; and dividing the EC message into the EC block number.
[00196] In an optional implementation, the hash value composed of the plurality of EC blocks is generated using a hash tree.
[00197] In an optional implementation, the hash tree includes a Merkle tree and the compound hash value is a root hash value of the Merkle tree.
[00198] In an optional implementation, the signature of the backup node associated with the first message includes a private key signature of the backup node associated with the first message.
[00199] In an optional implementation, at least a second message still includes at least one of the number of EC blocks.
[00200] In an optional implementation, checking whether the at least one second message is valid includes the following: generating a reconstructed hash tree using at least one of the number of EC blocks in at least one second message; determining a reconstructed composite hash value from the reconstructed hash tree; comparing the reconstructed composite hash value with a composite hash value in at least one second message; and determine whether the reconstructed composite hash value matches the composite hash values in at least one
Petition 870190097362, of 09/30/2019, p. 75/134
68/91 second message.
[00201] In an optional implementation, the unit of determination (1408) is further configured to determine that at least a second message is valid in response to the determination that the reconstructed composite hash value matches the composite hash values in the second messages .
[00202] In an optional implementation, the predetermined number of third messages that are identical includes the predetermined number of third messages with an identical set of signatures.
[00203] Figure 14 is a schematic diagram illustrating an internal functional module and a structure of a consensus device (1400). An execution body in essence can be an electronic device, and the electronic device includes the following: at least one processor; and a memory configured to store an executable instruction from at least one processor.
[00204] The at least one processor is configured to receive a first message from the primary node, where the first message includes a composite hash value associated with a number of EC blocks, where the number of EC blocks is generated by the primary node according to an EC code using a transaction request; send, via the backup node, a second message to the other network nodes in response to the receipt of the first message, where the second message includes the first message and a signature from the backup node associated with the first message; receive at least a second message from at least one backup node other than the backup node; verify that at least a second message is valid in response to receiving at least a second message from
Petition 870190097362, of 09/30/2019, p. 76/134
69/91 at least one backup node; determining whether a number of valid second messages exceeds a predetermined threshold; reconstruct the transaction request based on a subset of the number of second valid messages according to the EC code, in response to the determination that the number of second valid messages exceeds the predetermined threshold; send a third message to the other network nodes in response to the determination that the transaction request has been successfully rebuilt, where the third message includes a set of signatures that are in the second valid messages; receive at least a third message from at least one of the backup nodes; and executing the transaction request in response to receiving a predetermined number of third identical messages.
[00205] Optionally, the generation of the plurality of EC blocks according to an EC code includes the following: transforming the transaction request into an EC message using the EC code; and dividing the EC message into the EC block number.
[00206] Optionally, the hash value composed of the plurality of EC blocks is generated using a hash tree.
[00207] Optionally, the hash tree includes a Merkle tree and the compound hash value is a root hash value of the Merkle tree.
[00208] Optionally, the backup node signature associated with the first message includes a private key signature of the backup node associated with the first message.
[00209] Optionally, at least a second message also includes at least one of the number of EC blocks.
[00210] Optionally, checking whether the at least one second message is valid includes the following: generating a reconstructed hash tree using at least one of the number of EC blocks in at least
Petition 870190097362, of 09/30/2019, p. 77/134
70/91 a second message; determining a reconstructed composite hash value from the reconstructed hash tree; comparing the reconstructed composite hash value with a composite hash value in at least one second message; and determining whether the reconstructed composite hash value matches the composite hash values in at least one second message.
[00211] Optionally, the at least one processor is further configured to determine that the at least one second message is valid in response to the determination that the reconstructed composite hash value matches the composite hash values in the second messages.
[00212] Optionally, the predetermined number of third identical messages includes the predetermined number of third messages with an identical set of signatures.
[00213] Referring to Figure 15, Figure 15 is a diagram illustrating modules of a primary node change apparatus (1500), according to an implementation of the present invention. The apparatus (1500) for changing a primary node can be applied to a consensus system based on a reliable protocol technology. The apparatus (1500) can correspond to the implementations shown in Figures 7 to 9. For example, the apparatus (1500) can be implemented in a backup node of a trusted protocol network. The apparatus (1500) includes the following: a unit of determination (1502), configured to determine that a time change needs to be performed, where the time change causes a change from a current time with a current primary node to a new one epoch with a new primary node, where the current epoch comprises a consensus process to reach consensus between the number of network nodes using the primary node, the consensus process including three phases; The
Petition 870190097362, of 09/30/2019, p. 78/134
71/91 determination unit (1502), still configured to determine a respective backup node weight associated with each of the three phases of the consensus process at the current time, where the weight is a metric of a node qualification backup to be the new primary node; the determination unit (1502), still configured to determine a sum of weight for the backup node based on the respective weight of the backup node associated with each of the three phases at the current time; a transmitter or transmission unit (1504), configured to send an EPOCH_CHANGE message to the number of network nodes other than the network node in response to determining that the weight sum reaches a predetermined first threshold, where the message EPOCH_CHANGE indicates a requesting a change from the current epoch with the current primary node to the new epoch, with the backup node being the new primary node, and the EPOCH_CHANGE message includes the backup node weight sum; a receiving or receiving unit (1506), configured to receive at least one NEW_EPOCH message from at least one of the number of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation of the backup node as the new primary node being; a verification unit (1508), configured to verify that at least one NEW_EPOCH message is valid; the determination unit (1502), further configured to determine whether a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and the determination unit (1502), still configured to determine the backup node as the new primary node in the new era, in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold.
[00214] In an optional implementation, the determination
Petition 870190097362, of 09/30/2019, p. 79/134
72/91 of a respective backup node weight associated with each of the three phases of the consensus process at the present time includes determining a backup node weight for a first phase of the consensus process as the first value .
[00215] In an optional implementation, determining a respective backup node weight associated with each of the three phases of the consensus process at the current time includes the following: in response to determining a quorum verification failure in a second phase of the consensus process at the current time, determining a backup node weight for the second phase of the consensus process as a first value; and in response to determining the success of a quorum check in the second phase of the consensus process at the present time, determining the weight of the backup node for the second phase of the consensus process as a second value, where the first value is less than the second value.
[00216] In an optional implementation, the quorum check on the second phase of the network node includes receiving a predetermined number of ECHO messages from other network nodes.
[00217] In an optional implementation, determining a respective backup node weight associated with each of the three phases of the consensus process at the current time includes the following: in response to determining a quorum verification failure in a third phase of the consensus process at the present time, determining a backup node weight for the third phase of the consensus process as a third value; and in response to determining the success of a quorum check in the third phase of the current consensus process, determining the weight of the backup node for the third phase of the consensus process as a fourth value, where the third value it's smaller
Petition 870190097362, of 09/30/2019, p. 80/134
73/91 that the fourth value.
[00218] In an optional implementation, the third-phase quorum check for the network node includes receiving a predetermined number of messages accepted from other network nodes, where each of the messages accepted from other network nodes indicates that each of the other network nodes accepted a predetermined number of ECHO messages.
[00219] In an optional implementation, the EPOCH_CHANGE message also includes a set of signatures associated with a set of network nodes based on the number of network nodes, and where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message.
[00220] In an optional implementation, checking whether the at least one NEW_EPOCH message is valid includes checking whether the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid and verifying that the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid and includes verifying that the signature set in the EPOCH_CHANGE message is valid.
[00221] In an optional implementation, determining that a time change needs to be made includes determining that a time change needs to be performed in response to determining that consensus was not reached in the old time within a predetermined period of time .
[00222] In an optional implementation, the primary node change apparatus (1500) also includes the following: an operating unit (1510), configured to operate in the new season with the new primary node, in which the new season comprises a consensus process to reach consensus between the plurality of network nodes using the new node
Petition 870190097362, of 09/30/2019, p. 81/134
74/91 primary.
[00223] Figure 15 is a schematic diagram illustrating an internal functional module and a structure of a primary node alteration device (1500). An execution body in essence can be an electronic device, and the electronic device includes the following: at least one processor; and a memory configured to store an executable instruction from at least one processor.
[00224] At least one processor is configured to determine that a time change needs to be performed, where the time change causes a change from a current time with a current primary node to a new time with a new primary node, in whereas the current era comprises a consensus process to achieve consensus between the number of network nodes using the primary node, the consensus process including three phases; determine a respective backup node weight associated with each of the three phases of the consensus process at the current time, where the weight is a metric of a qualification of the backup node to be the new primary node; determining a weight sum for the backup node based on the respective weight of the backup node associated with each of the three phases at the current time; send an EPOCH_CHANGE message to the number of network nodes other than the network node in response to the determination that the weight sum reaches a predetermined first threshold, where the EPOCH_CHANGE message indicates a request for a change of the current time with the primary node current for the new era with the backup node being the new primary node and the message EPOCH_CHANGE includes the weight sum of the backup node; receive at least one NEW_EPOCH message from at least one of the number of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation from the backup node
Petition 870190097362, of 09/30/2019, p. 82/134
75/91 security as the new primary node; check if at least one NEW_EPOCH message is valid; determine whether a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined second threshold; and determining that the backup node is the new primary node in the new era in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold.
[00225] Optionally, determining a respective backup node weight associated with each of the three phases of the consensus process at the current time includes determining a backup node weight for a first phase of the backup process. consensus as a first value.
[00226] Optionally, determining a respective backup node weight associated with each of the three phases of the consensus process at the current time includes the following: in response to determining a quorum verification failure in a second phase of the consensus process at the present time, determine a backup node weight for the second phase of the consensus process as a first value; and in response to determining the success of a quorum check in the second phase of the consensus process at the present time, determining the weight of the backup node for the second phase of the consensus process as a second value, where the first value is less than the second value.
[00227] Optionally, the quorum check in the second phase for the network node includes receiving a predetermined number of ECHO messages from other network nodes.
[00228] Optionally, the determination of a respective weight of the backup node associated with each of the three phases
Petition 870190097362, of 09/30/2019, p. 83/134
76/91 of the current time consensus process includes the following: in response to determining a failure to verify the quorum in a third phase of the current time consensus process, determining a backup node weight for the third phase the consensus process as a third value; and in response to determining the success of a quorum check in the third phase of the current consensus process, determining the weight of the backup node for the third phase of the consensus process as a fourth value, where the third value is less than the fourth value.
[00229] Optionally, the quorum check on the third phase of the network node includes receiving a predetermined number of acceptance messages from other network nodes, where each acceptance message from other network nodes indicates that each of the others network nodes accepted a predetermined number of ECHO messages.
[00230] Optionally, the EPOCH_CHANGE message also includes a set of signatures associated with a set of network nodes outside the number of network nodes, and in which the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message.
[00231] Optionally, checking whether the at least one NEW_EPOCH message is valid includes checking that the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid and checking whether the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid includes verifying that the signature set in the EPOCH_CHANGE message is valid.
[00232] Optionally, the determination that a time change needs to be made includes the determination that a time change needs to be performed in response to the determination that consensus was not reached in the old time within a period of time
Petition 870190097362, of 09/30/2019, p. 84/134
77/91 predetermined.
[00233] Optionally, the at least one processor is still configured to operate in the new era with the new primary node, in which the new era comprises a consensus process to obtain consensus between the plurality of network nodes using the new primary node.
[00234] Referring to Figure 16, Figure 16 is a diagram illustrating modules of a primary node change apparatus (1600), according to an implementation of the present invention. The apparatus (1600) for changing a primary node can be applied to a consensus system based on a reliable protocol technology. The apparatus (1600) corresponds to the implementations shown in Figures 7 to 9. For example, the apparatus (1400) can be implemented on a network node of a trusted protocol network. The apparatus (1600) includes the following: a receiving unit or receiver (1602), configured to receive an EPOCH_CHANGE message from a backup node other than the network node, where the EPOCH_CHANGE message includes an indication that a change epoch needs to be performed, where the epoch change causes a change from a current epoch with a current primary node to a new epoch with a new primary node; a verification unit (1604), configured to verify that the message EPOCH_CHANGE is valid; a transmitter or transmission unit (1606), configured to send a NEW_EPOCH message to other network nodes in response to the verification that the EPOCH_CHANGE message is valid, where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message; the receiver or receiving unit (1602), further configured to receive at least one NEW_EPOCH message from at least one of the network node number other than the network node; the verification unit (1604), still configured to verify that at least one NEW_EPOCH message is
Petition 870190097362, of 09/30/2019, p. 85/134
78/91 valid; a determination unit (1608), configured to determine whether a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and the determination unit (1608), still configured to determine the backup node as the new primary node in the new era, in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold.
[00235] In an optional implementation, the EPOCH_CHANGE message includes a sum of weight associated with the backup node and a set of signatures associated with a set of network nodes out of the number of network nodes.
[00236] In an optional implementation, checking whether the EPOCH_CHANGE message is valid includes verifying that the weight sum in the EPOCH_CHANGE message is valid and verifying that the weight sum in the EPOCH_CHANGE message is valid, including verifying whether the signature set is valid .
[00237] In an optional implementation, verifying that the message from at least one NEW_EPOCH is valid includes verifying whether the message summary EPOCH_CHANGE in at least one NEW_EPOCH message is valid, and verifying whether the message summary EPOCH_CHANGE in at least one message NEW_EPOCH is valid includes checking if the signature set in the EPOCH_CHANGE message is valid.
[00238] Figure 16 is a schematic diagram that illustrates an internal functional module and a structure of a primary node alteration device (1600). An execution body in essence can be an electronic device, and the electronic device includes the following: one at least one processor; and a memory configured to store a
Petition 870190097362, of 09/30/2019, p. 86/134
79/91 executable instruction from at least one processor.
[00239] The at least one processor is configured to receive an EPOCH_CHANGE message from a backup node other than the network node, where the EPOCH_CHANGE message includes an indication that a time change needs to be performed, where the change epoch causes a change from a current epoch with a current primary node to a new epoch with a new primary node; check if the EPOCH_CHANGE message is valid; send a NEW_EPOCH message to the other network nodes in response to the verification that the EPOCH_CHANGE message is valid, where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message; receive at least one NEW_EPOCH message from at least one of several network nodes other than the network node; check if at least one NEW_EPOCH message is valid; determine whether a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and determining that the backup node is the new primary node in the new era in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold.
[00240] Optionally, the EPOCH_CHANGE message includes a sum of weight associated with the backup node and a set of signatures associated with a set of network nodes out of the number of network nodes.
[00241] Optionally, checking whether the EPOCH_CHANGE message is valid includes checking whether the weight sum in the EPOCH_CHANGE message is valid and checking whether the weight sum in the EPOCH_CHANGE message is valid includes checking whether the signature set is valid.
[00242] Optionally, checking if at least one
Petition 870190097362, of 09/30/2019, p. 87/134
80/91 NEW_EPOCH message is valid includes checking that the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid and checking whether the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid includes checking that the signature set in EPOCH_CHANGE message is valid.
[00243] Referring to Figure 17, Figure 17 is a diagram illustrating modules of a recovery apparatus (1700), according to an implementation of the present invention. The device (1700) for recovery can be applied to a consensus system based on a reliable protocol technology. The apparatus (1700) can correspond to the implementations shown in Figures 10 to 12. For example, the apparatus (1700) can be implemented on a network node of a trusted protocol network. The apparatus (1700) includes the following: a transmission unit (1702), configured to transmit, through a network node of a trust protocol network, a status request message to a number of other network nodes in the network trust protocol, in which the network node must retrieve a target transaction from a target sequence number; a receiver (1704) or a receiving unit (1704) configured to receive a number of status response messages from the number of other network nodes, wherein each of the status response message numbers includes a sequence number ; an identification unit (1706) configured to identify the target sequence number based on the target sequence number in response to the determination that a number of status response messages exceeds a predetermined threshold, where each of the message numbers state response comprises a target sequence number; a transmitter (1708) or a transmitting unit (1708), configured to send a request message to the number of other network nodes, where the request message requests a
Petition 870190097362, of 09/30/2019, p. 88/134
81/91 ECHO message from each of the other network nodes, where the ECHO message is a message transmitted by the number of other network nodes to obtain a consensus between the number of other network nodes in the target transaction that has the number target sequence and the ECHO message includes a part of the target transaction and a signature for each of the numbers of other network nodes; the receiver (1704) or the receiving unit (1704), additionally configured to receive a number of ECHO messages from the number of other network nodes; a determination unit (1710), configured to determine a number of valid ECHO messages from the number of ECHO messages, each of the number of valid ECHO messages including the target sequential number; a retrieval unit (1712), configured to retrieve the target transaction with the target sequence number on the network node based on the number of valid ECHO messages in response to the determination that the number of valid ECHO messages exceeds a predetermined threshold; and the transmitter (1708), still configured to send a message to the number of other network nodes, indicating that the network node has been recovered.
[00244] In an optional implementation, the number of network nodes includes a primary node and one or more backup nodes.
[00245] In an optional implementation, the network node is a primary node or a backup node.
[00246] In an optional implementation, the request message includes the target sequence number.
[00247] In an optional implementation, the recovery device (1700) also includes the following: a verification unit (1714), configured to check, for each of the number of other network nodes other than the network node, the message request before sending ECHO messages to the network node.
Petition 870190097362, of 09/30/2019, p. 89/134
82/91 [00248] In an optional implementation, the verification unit (1714) is further configured to verify that each of the ECHO messages is valid, in which the verification of whether each of the ECHO messages is valid includes the verification that each ECHO message is valid using a Merkel tree.
[00249] In an optional implementation, checking that each ECHO message is valid includes verifying that the signature on the ECHO message is valid.
[00250] In an optional implementation, each of the ECHO messages also includes at least one of several erasure code (EC) blocks associated with the target transaction, in which the number of EC blocks is generated according to an EC code using the target transaction.
[00251] In an optional implementation, retrieving the target transaction with the target sequence number on the network node based on the number of valid ECHO messages comprises reconstructing the target transaction using a subset of the plurality of EC blocks that are in the number of messages ECHO valid.
[00252] In an optional implementation, the message for the number of other network nodes indicating that the network node has been recovered includes a set of signatures on the number of valid ECHO messages and the target sequence number.
[00253] The system, device, module or unit illustrated in the previous implementations can be implemented using a computer chip or an entity, or they can be implemented using a product having a certain function. A typical implementation device is a computer, and the computer can be a personal computer, a laptop, a cell phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, a device
Petition 870190097362, of 09/30/2019, p. 90/134
83/91 that you receive and send email, a game console, a tablet computer, a wearable device or any combination of these devices.
[00254] For a process of implementing the functions and roles of each unit in the device, references can be made to a process of implementing corresponding steps in the previous method. Details are omitted here for simplicity.
[00255] As a device implementation basically corresponds to a method implementation, for related parties, references can be made to related descriptions in the method implementation. The appliance implementation described above is merely an example. The units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one position, or may be distributed across a plurality of network units. Some or all of the modules can be selected based on actual demands to achieve the objectives of the solutions of the present invention. A person skilled in the art can understand and implement the implementations of this application without creative efforts.
[00256] Figure 17 is a schematic diagram that illustrates an internal functional module and a structure of a recovery device (1700). An execution body, in essence, can be an electronic device, and the electronic device includes the following: at least one processor; and a memory configured to store an executable instruction from at least one processor.
[00257] The at least one processor is configured to transmit, through a network node of a trust protocol network, a status request message to several other network nodes of the trust protocol network, in which the network must retrieve a transaction
Petition 870190097362, of 09/30/2019, p. 91/134
84/91 target of a target sequence number; receiving a number of status response messages from the number of other network nodes, wherein each of the status response message numbers includes a sequence number; identifying the target sequence number based on the target sequence number in response to determining that a number of status response messages exceeds a predetermined threshold, wherein each of the status response message numbers comprises a target sequence number ; send a request message to the number of other network nodes, where the request message requests an ECHO message from each of the other network nodes, where the ECHO message is a message transmitted by each of the number of other network nodes network to reach consensus between the number of other network nodes in the target transaction with the target sequence number, and the ECHO message includes a part of the target transaction and a signature for each of the numbers of other network nodes; receiving a number of ECHO messages from the plurality of other network nodes; determining a number of valid ECHO messages from the number of ECHO messages, where each of the number of valid ECHO messages includes the target sequence number; retrieving the target transaction with the target sequence number on the network node based on the number of valid ECHO messages in response to the determination that the number of valid ECHO messages exceeds a predetermined threshold; and send a message to the number of other network nodes indicating that the network node has been recovered.
[00258] Optionally, the number of network nodes includes a primary node and one or more backup nodes.
[00259] Optionally, the network node is a primary node or a backup node.
[00260] Optionally, the request message includes the target sequence number.
Petition 870190097362, of 09/30/2019, p. 92/134
85/91 [00261] Optionally, at least one processor is further configured to check, for each of the numbers of other network nodes other than the network node, the request message before sending ECHO messages to the network node .
[00262] Optionally, at least one processor is still configured to verify that each of the ECHO messages is valid, in which the verification that each of the ECHO messages is valid includes the verification that each of the ECHO messages is valid using a tree Merkel.
[00263] Optionally, checking whether each ECHO message is valid includes checking the signature's validity in the ECHO message.
[00264] Optionally, each of the ECHO messages also includes at least one of a number of erasure code (EC) blocks associated with the target transaction, in which the number of EC blocks is generated according to an EC code using the transaction target.
[00265] Optionally, retrieving the target transaction with the target sequence number on the network node based on the number of valid ECHO messages includes reconstructing the target transaction using a subset of the number of EC blocks that are in the number of valid ECHO messages .
[00266] Optionally, the message for the number of other network nodes indicating that the network node has been recovered includes a set of signatures on the number of valid ECHO messages and the target sequence number.
[00267] The implementations of the subject and the actions and operations described in this description can be implemented in digital electronic circuits, in software or computer firmware tangibly
Petition 870190097362, of 09/30/2019, p. 93/134
86/91 embedded in computer hardware, including the structures disclosed in this description and their structural equivalents, or in combinations of one or more of them. The implementations of the subject matter described in this invention can be implemented as one or more computer programs, for example, one or more computer program instruction modules, encoded in a computer program vehicle, for execution or control of the device operation. data processing. The vehicle can be a non-transitory tangible computer storage medium. Alternatively, or in addition, the vehicle may be an artificially generated propagated signal, for example, an electrical, optical, electromagnetic signal generated by a machine that is generated to encode the information for transmission to the appropriate receiving apparatus to be performed by a Data processing. The computer storage medium can be or be part of a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. A computer storage medium is not a propagated signal.
[00268] The term "data processing apparatus" encompasses all types of data processing apparatus, devices and machines, including, for example, a programmable processor, a computer or several processors or computers. Data processing apparatus may include a special purpose logic circuit, for example, an FPGA (programmable logic gate array), an ASIC (application specific integrated circuit), or a GPU (graphics processing unit). The device may also include, in addition to hardware, code that creates an execution environment for computer programs, for example, code that constitutes the processor firmware, a protocol stack, a database management system, a system
Petition 870190097362, of 09/30/2019, p. 94/134
87/91 operational or a combination of one or more of them.
[00269] A computer program, which can also be referred to or described as a program, software, software application, application, module, software module, mechanism, script or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and can be implemented in any form, including as a supported program alone or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, where the environment can include one or more computers interconnected by a communication network data set in one or more locations.
[00270] A computer program can, but need not, correspond to a file in a file system. A computer program can be stored in a part of a file that contains other programs or data, for example, one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple files coordinates, for example, files that store one or more modules, sub - programs, or parts of code.
[00271] The processes and logical flows described in this invention can be performed by one or more computers running one or more computer programs to perform operations operating on input data and generating output. Logical processes and flows can also be performed by special-purpose logic circuits, for example, an FPGA, ASIC or GPU, or by a combination of special-purpose logic circuits and one or more programmed computers.
[00272] Computers suitable for the execution of a computer program can be based on microprocessors of
Petition 870190097362, of 09/30/2019, p. 95/134
88/91 general or special purpose, or any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer can include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated into special purpose logic circuits.
[00273] Generally, a computer will be attached to at least one non-transient computer-readable storage medium (also called computer-readable memory). The storage medium attached to the computer can be an internal computer component (for example, an integrated hard drive) or an external component (for example, universal serial bus (USB) hard drive or a storage system accessed over a network) . Examples of storage media may include, for example, magnetic disks, optical or magnetic magnets, solid state drives, network storage sources, such as cloud storage systems or other types of storage media. However, a computer does not need to have these devices. In addition, a computer can be incorporated into another device, for example, a cell phone, a personal digital assistant (PDA), an audio or video player, a game console, a GPS receiver or a portable storage device, for example example, a universal serial bus (USB) flash drive, to name just a few.
[00274] To provide interaction with a user, implementations of the subject matter described in this invention can be implemented on, or configured to communicate with, a computer having a display device, for example, an LCD monitor (display of
Petition 870190097362, of 09/30/2019, p. 96/134
89/91 liquid crystal), to display information to the user, and an input device by which the user can provide input to the computer, for example, a keyboard and a pointing device, for example, a mouse, a trackball or touchpad . Other types of devices can also be used to provide interaction with a user; for example, the feedback provided to the user can be any form of sensory feedback, for example, visual feedback, auditory feedback or tactile feedback; and user input can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents and receiving documents from a device used by the user; for example, by sending web pages to a web browser on a user's device in response to requests received from the web browser or interacting with an application running on a user's device, for example, a smartphone or electronic tablet. In addition, a computer can interact with a user by sending text messages or other forms of message to a personal device, for example, a smartphone that is running a messaging application and receiving responsive messages from the user in return.
[00275] This invention uses the term "configured for" in connection with systems, devices and components of computer programs. For a system of one or more computers to be configured to perform particular operations or actions, it means that the system has installed software, firmware, hardware or a combination of them that, in operation, cause the system to perform the operations or actions. For one or more computer programs to be configured to perform particular operations or actions means that one or more programs include instructions that, when executed by the data processing device,
Petition 870190097362, of 09/30/2019, p. 97/134
90/91 cause the device to perform operations or actions. For logic circuits with special purpose to be configured to perform particular operations or actions it means that the circuit has electronic logic that performs the operations or actions.
[00276] While this invention contains many implementation details, these should not be interpreted as limitations on the scope of what is being claimed, which is defined by the claims themselves, but rather as descriptions of features that may be specific to specific implementations. Certain features that are described in this invention in the context of separate implementations can also be realized in combination in a single implementation. On the other hand, several characteristics that are described in the context of a single implementation can also be realized in several implementations separately or in any suitable sub-combination. In addition, although the characteristics can be described above as acting on certain combinations and even initially claimed as such, one or more characteristics of a claimed combination can in some cases be excised from the combination, and the claim can be directed to a sub- combination or variation of a sub-combination.
[00277] Likewise, while operations are illustrated in the drawings and recited in the claims in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all operations illustrated executed to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. In addition, the separation of various modules and system components in the implementations described above should not be understood as requiring such separation in all implementations, and should
Petition 870190097362, of 09/30/2019, p. 98/134
It should be understood that the program components and systems described can generally be integrated into a single software product or packaged into multiple software products.
[00278] Particular implementations of the subject have been described. Other implementations are within the scope of the following claims. For example, the actions cited in the claims can be carried out in a different order and still achieve desirable results. As an example, the processes illustrated in the accompanying Figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In some cases, multitasking and parallel processing can be advantageous.

权利要求:
Claims (42)
[1]
Claims
1. METHOD IMPLEMENTED BY COMPUTER to perform a change of a primary node in a trust protocol network (blockchain), characterized by comprising a plurality of network nodes, in which the plurality of network nodes comprises the primary node and one or plus backup nodes, the method you understand:
determine, by a backup node, that a time change needs to be performed, where the time change causes a change from a current time with a current primary node to a new time with a new primary node, where the The current era comprises a consensus process to achieve consensus between the plurality of network nodes using the primary node, the consensus process comprising three phases:
determine, by the backup node, a respective backup node weight associated with each of the three phases of the consensus process at the current time, where the weight is a metric of a backup node qualification for be the new primary node;
determine, by the backup node, a sum of weight for the backup node based on the respective weight of the backup node associated with each of the three phases at the current time;
in response to the determination that the weight sum reaches a predetermined first threshold, it sends, through the backup node, an EPOCH_CHANGE message to the plurality of network nodes other than the network node, in which the message EPOCH_CHANGE indicates a request changing the current epoch with the current primary node to the new epoch, with the backup node being the new primary node, and the message EPOCH_CHANGE comprises the sum of the weight of the backup node;
receive at least one NEW_EPOCH message from at least one of the plurality of network nodes by the backup node
Petition 870190097362, of 09/30/2019, p. 100/134
[2]
2/17 different from the backup node, where the NEW_ EPOCH message indicates a confirmation that the backup node is the new primary node;
verify, by the backup node, that at least one NEW_EPOCH message is valid;
determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold, determine, by the backup node, that the backup node is the new primary node in the new era.
2. METHOD, according to claim 1, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the current time comprises the determination of a weight of the backup node for a first phase of the consensus process as a first value.
[3]
3. METHOD, according to claim 1, characterized by determining a respective weight of the backup node associated with each of the three phases of the consensus process at the current time comprises:
in response to determining a failure to verify the quorum in a second phase of the consensus process at the present time, determine a backup node weight for the second phase of the consensus process as a first value; and in response to determining the success of a quorum check in the second phase of the current consensus process, determining the weight of the backup node for the second phase of the
Petition 870190097362, of 09/30/2019, p. 101/134
3/17 consensus as a second value, where the first value is less than the second value.
[4]
4. METHOD, according to claim 3, characterized by the quorum verification in the second phase for the network node to understand receiving a predetermined number of ECHO messages from other network nodes.
[5]
5. METHOD, according to claim 1, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the current time comprise:
in response to determining a quorum verification failure in a third phase of the consensus process at the present time, determine a backup node weight for the third phase of the consensus process as a third value; and in response to determining the success of a quorum check in the third phase of the consensus process at the present time, determine the weight of the backup node for the third phase of the consensus process as a fourth value, where the third value is less than the fourth value.
[6]
6. METHOD, according to claim 5, characterized by the verification of the quorum in the third phase for the network node to understand receiving a predetermined number of acceptance messages from other network nodes, in which each of the acceptance messages from other nodes network indicates that each of the other network nodes has accepted a predetermined number of ECHO messages.
[7]
7. METHOD, according to claim 1, characterized by the message EPOCH_CHANGE further comprising a set of signatures associated with a set of network node from the plurality of
Petition 870190097362, of 09/30/2019, p. 102/134
4/17 network nodes, and where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message.
[8]
8. METHOD, according to claim 7, characterized by verifying that at least one valid NEW_EPOCH message is valid, comprises verifying whether the summary of the EPOCH_CHANGE message in the at least one NEW_EPOCH message is valid, and in which verifying whether the summary of EPOCH_CHANGE message in at least one NEW_EPOCH message is valid comprises verifying that the signature set in the EPOCH_CHANGE message is valid.
[9]
9. METHOD, according to claim 1, characterized by the determination that a time change needs to be carried out understand the determination that a time change needs to be carried out in response to the determination that consensus was not reached in the old time within a predetermined period of time.
[10]
10. METHOD, according to claim 1, characterized by comprising still operating in the new era with the new primary node, in which the new era comprises a consensus process to reach a consensus between the plurality of network nodes using the new node primary.
[11]
11. COMPUTER IMPLEMENTED METHOD for making a change to a primary node in a trust protocol network that comprises a plurality of network nodes, where the plurality of network nodes comprises the primary node and one or more copy nodes security, the method characterized by comprising:
receive, via a network node, an EPCOH_CHANGE message from a backup node other than the network node, where the EPOCH_CHANGE message comprises an indication that a time change needs to be performed, where the time change causes an changing a current season with a current primary node to a new season with a new
Petition 870190097362, of 09/30/2019, p. 103/134
5/17 primary node;
check, by the network node, if the EPOCH_CHANGE message is valid;
in response to verifying that the EPOCH_CHANGE message is valid, send, via the network node, a NEW_EPOCH message to the other network nodes, where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message;
receiving at least one NEW_EPOCH message from at least one of the plurality of network nodes other than the network node by the network node;
check, by the network node, if at least one NEW-EPOCH message is valid;
determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold, determine, by the network node, the backup node as the new primary node in the new era.
[12]
12. METHOD, according to claim 11, characterized by the message EPOCH_CHANGE comprising a sum of weight associated with the backup node and a set of signatures associated with a set of network nodes from the plurality of network nodes.
[13]
13. METHOD, according to claim 12, characterized by checking whether the EPOCH_CHANGE message is valid, understanding whether the weight sum in the EPOCH_CHANGE message is valid, in which checking whether the sum of weight in the EPOCH_CHANGE message is valid, understanding whether the signature set is valid.
Petition 870190097362, of 09/30/2019, p. 104/134
6/17
[14]
14. METHOD, according to claim 12, characterized by checking whether the at least one NEW_EPOCH message is valid, understanding whether the message summary EPOCH_CHANGE in the at least one NEW_EPOCH message is valid, and at which checking whether the message summary EPOCH_CHANGE in at least one NEW_EPOCH message is valid comprises verifying that the signature set in the EPOCH_CHANGE message is valid.
[15]
15. NON-TRANSITIONAL STORAGE MEDIA, readable by computer, attached to one or more computers and configured with instructions executable by one or more computers, characterized by being for:
determine, by a backup node of a trust protocol network comprising a plurality of network nodes, that an epoch change needs to be made, in which the plurality of network nodes comprise a primary node and one or more backup nodes, comprising the backup node, where the epoch change causes a change from a current epoch with a current primary node to a new epoch with a new primary node, where the current epoch comprises a process consensus to achieve consensus between the plurality of network nodes using the primary node, the consensus process comprising three phases;
determine, by the backup node, a respective backup node weight associated with each of the three phases of the consensus process at the current time, where the weight is a metric of a backup node qualification for be the new primary node;
determine, by the backup node, a sum of weight for the backup node based on the respective weight of the backup node associated with each of the three phases at the current time;
Petition 870190097362, of 09/30/2019, p. 105/134
7/17 in response to the determination that the weight sum reaches a first predetermined threshold, send, through the backup node, an EPOCH_CHANGE message to the plurality of network nodes other than the network node, in which the message EPOCH_CHANGE indicates a request to change the current epoch with the current primary node to the new epoch, with the backup node being the new primary node, and the EPOCH_CHANGE message comprises the weight sum of the backup node;
receive, by the backup node, at least one NEW_EPOCH message from at least one of the plurality of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation that the backup node is the new primary node;
verify, by the backup node, that at least one NEW_EPOCH message is valid;
determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold, determine, by the backup node, the backup node to be the new primary node in the new era.
[16]
16. Computer-readable NON-TRANSITIONAL STORAGE MEDIA, according to claim 15, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the present time, to understand determining a weight of the backup node for a first phase of the consensus process as a first value.
[17]
17. LEGIBLE NON-TRANSITIONAL STORAGE MEDIA
Petition 870190097362, of 09/30/2019, p. 106/134
8/17 per computer, according to claim 15, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the current time comprise:
in response to determining a quorum verification failure in a second phase of the consensus process at the present time, determine a backup node weight for the second phase of the consensus process as a first value; and in response to determining the success of a quorum check in the second phase of the current consensus process, determining the weight of the backup node for the second phase of the consensus process as a second value, where the first value is less than the second value.
[18]
18. NON-TRANSITIONAL computer-readable STORAGE MEDIA according to claim 17, characterized by the quorum verification in the second phase for the network node to understand receiving a predetermined number of ECHO messages from other network nodes.
[19]
19. Computer-readable NON-TRANSITIONAL STORAGE MEDIA, according to claim 15, characterized by the determination of the respective weight of the backup node associated with each of the three phases of the consensus process at the present time, comprising:
in response to determining a quorum verification failure in a third phase of the consensus process at the present time, determine a backup node weight for the third phase of the consensus process as a third value; and in response to determining the success of a
Petition 870190097362, of 09/30/2019, p. 107/134
9/17 quorum in the third phase of the consensus process at the current time, determine the weight of the backup node for the third phase of the consensus process as a fourth value, where the third value is less than the fourth value.
[20]
20. Computer-readable NON-TRANSITIONAL MEDIA according to claim 19, characterized by the quorum verification in the third phase for the network node to understand receiving a predetermined number of acceptance messages from other network nodes, in which each of acceptance messages from other network nodes indicates that each of the other network nodes accepted a predetermined number of ECHO messages.
[21]
21. Computer-readable NON-TRANSITIONAL MEDIA according to claim 15, characterized by the EPOCH_CHANGE message further comprising a set of signatures associated with a set of network nodes outside the plurality of network nodes, and in which the message NEW_EPOCH comprises a summary of the EPOCH_CHANGE message.
[22]
22. Computer-readable NON-TRANSITIONAL MEDIA according to claim 21, characterized by verifying that at least one valid NEW_EPOCH message is valid, understanding that the summary of the EPOCH_CHANGE message in the at least one NEW_EPOCH message is valid and in that verify that the summary of the EPOCH_CHANGE message in at least one NEW_EPOCH message is valid and consists of verifying that the signature set in the EPOCH_CHANGE message is valid.
[23]
23. Computer-readable NON-TRANSITIONAL MEDIA according to claim 15, characterized by determining that a change of season needs to be carried out understand
Petition 870190097362, of 09/30/2019, p. 108/134
10/17 determine that an epoch change needs to be made in response to the determination that consensus was not reached in the ancient epoch within a predetermined period of time.
[24]
24. Computer-readable NON-TRANSITIONAL MEDIA according to claim 15, characterized by still being configured with instructions executable by one or more computers to:
operate in the new era with the new primary node, where the new era comprises a consensus process to achieve consensus among the plurality of network nodes using the new primary node.
[25]
25. SYSTEM, characterized by including:
one or more computers; and one or more computer-readable memories attached to one or more computers and configured with instructions executable by one or more computers to:
determining, by a backup node of a trust protocol network comprising a plurality of network nodes, that an epoch change needs to be made, in which the plurality of network nodes comprise a primary node and one or more nodes backup copy, comprising the backup node, where the epoch change causes a change from a current epoch with a current primary node to a new epoch with a new primary node, where the current epoch comprises a process of consensus to achieve consensus between the plurality of network nodes using the primary node, the consensus process comprising three phases;
determine, by the backup node, a respective backup node weight associated with each of the three phases of the consensus process at the current time, where the weight is a metric of a backup node qualification for be the new primary node;
Petition 870190097362, of 09/30/2019, p. 109/134
11/17 determine, by the backup node, a sum of weight for the backup node based on the respective weight of the backup node associated with each of the three phases at the current time;
in response to the determination that the weight sum reaches a predetermined first threshold, send, through the backup node, an EPOCH_CHANGE message to the plurality of network nodes other than the network node, in which the message EPOCH_CHANGE indicates a request for changing the current epoch with the current primary node to the new epoch, with the backup node being the new primary node, and the EPOCH_CHANGE message comprises the weight sum of the backup node;
receive, by the backup node, at least one NEW_EPOCH message from at least one of the plurality of network nodes other than the backup node, where the NEW_EPOCH message indicates a confirmation that the backup node is the new primary node;
verify, by the backup node, that at least one NEW_EPOCH message is valid;
determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a second predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold, determine, by the backup node, the backup node to be the new primary node in the new era.
[26]
26. SYSTEM, according to claim 25, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the present time comprising determining a weight of the backup node
Petition 870190097362, of 09/30/2019, p. 110/134
12/17 for a first phase of the consensus process to be a first value.
[27]
27. SYSTEM, according to claim 25, characterized by determining the respective weight of the backup node associated with each of the three phases of the consensus process at the present time comprise:
in response to determining a quorum verification failure in a second phase of the consensus process at the present time, determine a backup node weight for the second phase of the consensus process as a first value; and in response to determining the success of a quorum check in the second phase of the current consensus process, determining the weight of the backup node for the second phase of the consensus process as a second value, where the first value is less than the second value.
[28]
28. SYSTEM, according to claim 27, characterized by the quorum verification in the second phase for the network node to understand receiving a predetermined number of ECHO messages from other network nodes.
[29]
29. SYSTEM, according to claim 25, characterized by the determination of a respective weight of the backup node associated with each of the three phases of the consensus process at the current time comprise:
in response to determining a quorum verification failure in a third phase of the consensus process at the present time, determine a backup node weight for the third phase of the consensus process as a third value; and in response to determining the success of a quorum check in the third phase of the current consensus process,
Petition 870190097362, of 09/30/2019, p. 111/134
13/17 weight of the backup node for the third phase of the consensus process as a fourth value, where the third value is less than the fourth value.
[30]
30. SYSTEM, according to claim 29, characterized by the verification of the quorum in the third phase for the network node to receive a predetermined number of acceptance messages from other network nodes, in which each of the messages of acceptance of other network nodes indicates that each of the other network nodes has accepted a predetermined number of ECHO messages.
[31]
31. SYSTEM, according to claim 25, characterized by the EPOCH_CHANGE message further comprising a set of signatures associated with a set of network nodes from the plurality of network nodes, and in which the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message .
[32]
32. SYSTEM, according to claim 31, characterized by checking whether the at least one valid NEW_EPOCH message is valid, understanding whether the summary of the EPOCH_CHANGE message in the at least one NEW_EPOCH message is valid, and at which checking whether the summary of the message EPOCH_CHANGE message in at least one NEW_EPOCH message is valid and comprises verifying that the signature set in the EPOCH_CHANGE message is valid.
[33]
33. SYSTEM, according to claim 25, characterized by the determination that a time change needs to be made understand to determine that a time change needs to be performed in response to the determination that consensus was not reached in the old time within a predetermined period of time.
[34]
34. SYSTEM, according to claim 25, characterized in that the computer memories are still configured with
Petition 870190097362, of 09/30/2019, p. 112/134
14/17 instructions executable by one or more computers to:
operate in the new era with the new primary node, where the new era comprises a consensus process to achieve consensus between the plurality of network nodes using the new primary node.
[35]
35. NON-TRANSITIONAL STORAGE MEDIA legible by computer coupled to one or more computers and configured with instructions executable by one or more computers, characterized by being for:
receiving, by a network node of a trust protocol network comprising a plurality of network nodes, an EPCOH_CHANGE message from a backup node of the trust protocol network node other than the network node, wherein the plurality of network nodes comprises a primary node and one or more backup nodes, where the EPOCH_CHANGE message comprises an indication that a time change needs to be performed, where the time change causes a change to a current time with a current primary node for a new era with a new primary node;
check, by the network node, if the EPOCH_CHANGE message is valid;
in response to verifying that the EPOCH_ CHANGE message is valid, send, via the network node, a NEW_EPOCH message to the other network nodes, where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message;
receiving at least one NEW_EPOCH message from at least one of the plurality of network nodes other than the network node by the network node;
check, by the network node, if at least one NEW_EPOCH message is valid;
Petition 870190097362, of 09/30/2019, p. 113/134
15/17 determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold, determine, by the network node, the backup node to be the new primary node in the new era.
[36]
36. Computer readable NON-TRANSITIONAL MEDIA according to claim 35, characterized by the message EPOCH_CHANGE comprising a sum of weight associated with the backup node and a set of signatures associated with a set of network nodes of the plurality of network nodes.
[37]
37. Computer readable NON-TRANSITIONAL MEDIA according to claim 36, characterized by checking whether the EPOCH_CHANGE message is valid, understanding whether the weight sum in the EPOCH_CHANGE message is valid, in which the verification if the weight sum in the EPOCH_CHANGE message it is valid to verify that the signature set is valid.
[38]
38. Computer-readable NON-TRANSITIONAL MEDIA according to claim 36, characterized by verifying that at least one NEW_EPOCH message is valid, understanding that the summary of the EPOCH_CHANGE message in the at least one NEW_EPOCH message is valid and in which verifying that the EPOCH_CHANGE message digest in at least one NEW_EPOCH message is valid comprises verifying that the signature set in the EPOCH_CHANGE message is valid.
[39]
39. SYSTEM, characterized by including:
one or more computers; and one or more computer-readable memories coupled to a
Petition 870190097362, of 09/30/2019, p. 114/134
16/17 or more computers and configured with instructions executable by one or more computers to:
receiving, by a network node of a trust protocol network comprising a plurality of network nodes, an EPCOH_CHANGE message from a backup node of the trust protocol network node other than the network node, wherein the plurality of network nodes comprises a primary node and one or more backup nodes, where the EPOCH_CHANGE message comprises an indication that a time change needs to be performed, where the time change causes a change to a current time with a current primary node for a new era with a new primary node;
check, by the network node, if the EPOCH_CHANGE message is valid;
in response to verifying that the EPOCH_ CHANGE message is valid, send, via the network node, a NEW_EPOCH message to the other network nodes, where the NEW_EPOCH message comprises a summary of the EPOCH_CHANGE message;
receive, by the network node, at least one NEW_EPOCH message from at least one among the plurality of network nodes other than the network node;
check, by the network node, if at least one NEW_EPOCH message is valid;
determine, by the backup node, if a number of valid NEW_EPOCH messages from at least one NEW_EPOCH message exceeds a predetermined threshold; and in response to the determination that the number of valid NEW_EPOCH messages exceeds the predetermined threshold, determine, by the network node, the backup node to be the new primary node in the new era.
Petition 870190097362, of 09/30/2019, p. 115/134
17/17
[40]
40. SYSTEM, according to claim 39, characterized by the message EPOCH_CHANGE comprising a sum of weight associated with the backup node and a set of signatures associated with a set of network nodes of the plurality of network nodes.
[41]
41. SYSTEM, according to claim 40, characterized by checking whether the EPOCH_CHANGE message is valid comprises verifying whether the weight sum in the EPOCH_CHANGE message is valid, in which verifying whether the weight sum in the EPOCH_CHANGE message is valid comprises verifying whether the set of signatures are valid.
[42]
42. SYSTEM, according to claim 40, characterized by checking whether the at least one NEW_EPOCH message is valid, understanding whether the message summary EPOCH_CHANGE in the at least one NEW_EPOCH message is valid, and at which checking whether the message summary EPOCH_CHANGE in at least one NEW_EPOCH message is valid and comprises verifying that the signature set in the EPOCH_CHANGE message is valid.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112019016598A2|2020-03-31|COMPUTER IMPLEMENTED METHODS, NON-TRANSITIONAL STORAGE MEDIA AND SYSTEMS

---

RU2723072C1|2020-06-08|Achieving consensus between network nodes in distributed system

---

ES2818597T3|2021-04-13|Perform a recovery process for a network node on a distributed system

---

TWI729880B|2021-06-01|Shared blockchain data storage based on error correction coding in trusted execution environments

---

TW202111586A|2021-03-16|Shared blockchain data storage based on error correction coding in trusted execution environments

同族专利:

---

公开号 | 公开日

---

WO2019072296A2|2019-04-18|

---

JP6726367B2|2020-07-22|

---

RU2716558C1|2020-03-12|

---

EP3566397A4|2020-03-04|

---

US10630672B2|2020-04-21|

---

CN111543026A|2020-08-14|

---

KR102134549B1|2020-07-27|

---

US20190288993A1|2019-09-19|

---

US20200195625A1|2020-06-18|

---

SG11201907346UA|2019-09-27|

---

ZA201905274B|2021-10-27|

---

EP3566397B1|2021-07-28|

---

CA3053208A1|2019-04-18|

---

TW202023232A|2020-06-16|

---

AU2018348336B2|2020-07-23|

---

TWI705690B|2020-09-21|

---

KR20200074912A|2020-06-25|

---

EP3566397A2|2019-11-13|

---

AU2018348336A1|2020-07-02|

---

MX2019009548A|2019-09-26|

---

WO2019072296A3|2019-08-29|

---

JP2020513170A|2020-04-30|

---

CA3053208C|2020-10-06|

---

US10791107B2|2020-09-29|

---

PH12019501871A1|2020-06-01|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US4309569A|1979-09-05|1982-01-05|The Board Of Trustees Of The Leland Stanford Junior University|Method of providing digital signatures|

---

EP0135499B1|1983-02-09|1990-05-02|International Business Machines Corporation|A method for achieving multiple processor agreement optimized for no faults|

---

US7249259B1|1999-09-07|2007-07-24|Certicom Corp.|Hybrid signature scheme|

---

US6671821B1|1999-11-22|2003-12-30|Massachusetts Institute Of Technology|Byzantine fault tolerance|

---

US6985956B2|2000-11-02|2006-01-10|Sun Microsystems, Inc.|Switching system|

---

US6931431B2|2001-01-13|2005-08-16|International Business Machines Corporation|Agreement and atomic broadcast in asynchronous networks|

---

US7502360B2|2005-03-04|2009-03-10|Itt Manufacturing Enterprises, Inc.|Method and apparatus for dynamic neighbor discovery within wireless networks using time division multiple access |

---

US8819102B2|2007-07-03|2014-08-26|Cisco Technology, Inc.|Method and system for managing message communications|

---

WO2010071882A2|2008-12-19|2010-06-24|Watchguard Technologies, Inc.|Cluster architecture for network security processing|

---

JP5427574B2|2009-12-02|2014-02-26|株式会社日立製作所|Virtual computer migration management method, computer using the migration management method, virtualization mechanism using the migration management method, and computer system using the migration management method|

---

CA2849930C|2011-10-25|2017-06-20|Nicira, Inc.|Chassis controllers for converting universal flows|

---

US9471622B2|2012-04-30|2016-10-18|International Business Machines Corporation|SCM-conscious transactional key-value store|

---

JP2014178793A|2013-03-14|2014-09-25|Hitachi Ltd|Information processing system|

---

JP2015146165A|2014-02-04|2015-08-13|日本電信電話株式会社|Fault resistance signal processor and fault resistance signal processing method|

---

WO2016003708A1|2014-07-01|2016-01-07|Sas Institute Inc.|Systems and methods for fault tolerant communications|

---

WO2016155002A1|2015-04-03|2016-10-06|Yahoo! Inc.|Method and system for data recovery in a data system|

---

EP3345360B1|2015-09-04|2021-03-03|Nec Corporation|Method for storing an object on a plurality of storage nodes|

---

WO2017136527A1|2016-02-05|2017-08-10|Manifold Technology, Inc.|Blockchain-enhanced database|

---

US10204341B2|2016-05-24|2019-02-12|Mastercard International Incorporated|Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees|

---

EP3281115B1|2016-10-04|2019-06-19|Nec Corporation|Method and system for byzantine fault-tolerance replicating of data on a plurality of servers|

---

US10360191B2|2016-10-07|2019-07-23|International Business Machines Corporation|Establishing overlay trust consensus for blockchain trust validation system|

---

US10158527B2|2016-10-28|2018-12-18|International Business Machines Corporation|Changing an existing blockchain trust configuration|

---

US10554746B2|2016-11-14|2020-02-04|International Business Machines Corporation|Decentralized immutable storage blockchain configuration|

---

US10311230B2|2016-12-24|2019-06-04|Cisco Technology, Inc.|Anomaly detection in distributed ledger systems|

---

CN106529951A|2016-12-30|2017-03-22|杭州云象网络技术有限公司|Node consensus verification method under league chain network through asynchronous mode|

---

CN107391320B|2017-03-10|2020-07-10|创新先进技术有限公司|Consensus method and device|

---

CN107360206B|2017-03-29|2020-03-27|创新先进技术有限公司|Block chain consensus method, equipment and system|

---

US20180308091A1|2017-04-21|2018-10-25|Vmware, Inc.|Fairness preserving byzantine agreements|

---

CN107423152B|2017-04-24|2019-05-21|杭州趣链科技有限公司|A kind of block chain common recognition node automatic recovery method|

---

EP3632037A4|2017-05-22|2020-04-08|Visa International Service Association|Network for improved verification speed with tamper resistant data|

---

CN112804349A|2017-07-14|2021-05-14|创新先进技术有限公司|Method and device for processing consensus request in block chain consensus network and electronic equipment|

---

US11023608B2|2017-09-15|2021-06-01|Identify3D, Inc.|System and method for data management and security for digital manufacturing|

---

US11165862B2|2017-10-24|2021-11-02|0Chain, LLC|Systems and methods of blockchain platform for distributed applications|

---

CN108306760A|2017-12-28|2018-07-20|中国银联股份有限公司|For making the self-healing method and apparatus of managerial ability in a distributed system|

---

CN108365993B|2018-03-09|2020-04-28|深圳前海微众银行股份有限公司|Block link point dynamic changing method, system and computer readable storage medium|

---

CN108616596B|2018-05-09|2020-12-25|南京邮电大学|Block chain self-adaptive consensus method based on dynamic authorization and network environment perception|

---

CN108768749B|2018-06-21|2021-03-30|佛山科学技术学院|Node isolation self-recovery method and device based on block chain|

---

JP6726367B2|2018-12-13|2020-07-22|アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ|Changing the primary node in a distributed system|

---

BR112019014815A2|2018-12-13|2020-02-27|Alibaba Group Holding Limited|COMPUTER IMPLEMENTED METHOD, LEGIBLE STORAGE MEDIA BY NON-TRANSITIONAL COMPUTER AND SYSTEM|

---

MX2019008861A|2018-12-13|2019-09-11|Alibaba Group Holding Ltd|Achieving consensus among network nodes in a distributed system.|US10599835B2|2018-02-06|2020-03-24|Vmware, Inc.|32-bit address space containment to secure processes from speculative rogue cache loads|

---

US10713133B2|2018-06-11|2020-07-14|Vmware, Inc.|Linear view-change BFT|

---

US10747629B2|2018-06-11|2020-08-18|Vmware, Inc.|Linear view-change BFT with optimistic responsiveness|

---

MX2019008861A|2018-12-13|2019-09-11|Alibaba Group Holding Ltd|Achieving consensus among network nodes in a distributed system.|

---

BR112019014815A2|2018-12-13|2020-02-27|Alibaba Group Holding Limited|COMPUTER IMPLEMENTED METHOD, LEGIBLE STORAGE MEDIA BY NON-TRANSITIONAL COMPUTER AND SYSTEM|

---

JP6726367B2|2018-12-13|2020-07-22|アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ|Changing the primary node in a distributed system|

---

US11048596B2|2018-12-14|2021-06-29|Nokia Technologies Oy|Hierarchical weighted consensus for permissioned blockchains|

---

US10938750B2|2019-03-18|2021-03-02|Advanced New Technologies Co., Ltd.|Consensus system downtime recovery|

---

KR102230829B1|2019-03-18|2021-03-23|어드밴스드 뉴 테크놀로지스 씨오., 엘티디.|Consensus system downtime recovery|

---

SG11201908387SA|2019-03-18|2019-10-30|Alibaba Group Holding Ltd|Consensus system downtime recovery|

---

CN110049051B|2019-04-22|2020-08-11|成都四方伟业软件股份有限公司|Request verification method, device, storage medium and alliance chain verification system|

---

EP3701701A4|2019-06-05|2020-12-30|Alibaba Group Holding Limited|Consensus system and method|

---

US10896171B2|2019-06-13|2021-01-19|Tyson York Winarski|Big data blockchains with Merkle trees|

---

WO2021091548A1|2019-11-06|2021-05-14|Visa International Service Association|Blockchain enabled fault tolerance|

---

AU2019323043A1|2019-11-13|2021-05-27|AlipayInformation Technology Co., Ltd.|Blockchain data storage based on error correction code for permissioned blockchain network|

---

CN111526219B|2020-07-03|2021-02-09|支付宝信息技术有限公司|Alliance chain consensus method and alliance chain system|

---

CN111522800B|2020-07-03|2020-10-30|支付宝信息技术有限公司|Block chain consensus method, node and system of badger Byzantine fault-tolerant consensus mechanism|

---

EP3957025A4|2020-07-03|2022-02-23|Alipay Hangzhou Inf Tech Co Ltd|System and method for providing privacy and security protection in blockchain-based private transactions|

---

CN111526216B|2020-07-03|2020-09-22|支付宝信息技术有限公司|Consensus method and system in alliance chain|

---

CN111526217B|2020-07-03|2020-10-09|支付宝信息技术有限公司|Consensus method and system in block chain|

---

CN112068978A|2020-08-27|2020-12-11|恒宝股份有限公司|Method for prolonging timing period of VIEW-CHANGE secondary start timer|

法律状态:
2021-04-06| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |

---

2021-04-27| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |

---

2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

PCT/CN2018/120873|WO2019072296A2|2018-12-13|2018-12-13|Performing a change of primary node in a distributed system|

---